Kann jemand erklären, was ist das besondere an der programmiersprache Python? Ich habe bisher keine Kenntnisse über Python. Vor ein paar Jahren hörte man überall Perl. Heute hört man davon nichts mehr. Heute hört man nur noch Python. Warum? Was ist an Python so gut?
:
Verschoben durch Admin
> Was ist an Python so gut?
Python ist ungiftig.
osman schrieb: > Kann jemand erklären, was ist das besondere an der programmiersprache > Python? Ja. Vorwort: Bei anderen Programmiersprachen dienen spezielle Wörter oder Zeichen zum Kennzeichnen von Blöcken. Also if (a<3) { blablabla... } bei C if a<3 then begin blablabla... end bei Pascal. Und bei Python gibt es so etwas überhaupt nicht. Dort müssen Blöcke durch Einrückungen gekennzeichnet werden. Ich halte das für gequirlten Irrsinn. Programmiersprachen sollen gefälligst klar lesbare Zeichen/Worte haben, um damit Blöcke zu kennzeichnen! Aber hier bei Python haben wir stattdessen unterschiedliche Anzahl von 'white space' Zeichen! Und was passiert dort, wenn man 1x Space und dann 1x Tab schreibt? Nein, nicht mit mir. W.S.
W.S. schrieb: > Und was passiert dort, wenn man 1x Space und dann 1x Tab schreibt? Probiere es doch. Es darf nicht gemischt werden.
osman schrieb: > Vor ein paar Jahren hörte > man überall Perl. Heute hört man davon nichts mehr. Heute hört man nur > noch Python. Also geht es um Interpretierte/Scriptsprachen. Jeder Softwareentwickler muss eine Scriptsprache können. Das hängt auch mit dem Umfeld zusammen in dem du dich bewegst. Ich hatte mal viel mit Perl gemacht, weil das auf jedem Server für CGI unterstützt wurde. Das ist aber schon Jahrzehnte her. Python hab ich schon mal gehört. -) Brauch ich nicht, erscheint mir als Hype. Irgendwer Anders wird sagen, du brauchst PHP (ich nenn das immer Internet-Basic). Frag im Nachbarzimmer, dann ist es Rubi. Frägst du mich, dann ist es Tcl. Nimm die Sprache die dir gefällt oder die, die von dir gefordert wird. Witzig ist, wann die Sprachen entwickelt wurden: Ruby: Mitte 1990 Perl: 1987 Tcl: 1988 PHP: 1995 Python: Anfang 1990 Die liegen innerhalb eines Jahrzehnts und haben sich bis jetzt gehalten.
Das ist meine meine Erfahrung mit Python. Ob man es verwenden möchte kann ja jeder selbst entscheiden. Für schnelle Experimente finde ich die Sprache sehr schön. - Als Scriptsprache muss kein Compiler aufgesetzt werden. - Die Bibliothek bringt viele Funktionen, wie z.B. Codierungen, Parser und Webanfragen mit. - Fehler werden mit Exception und Begründung geworfen und führen nicht einfach zu einer Accessviolation. - Die Syntax ist übersichtlicher als bei anderen Scriptsprachen. Als Nachteil für größere Projekte empfinde ich die fehlende Typisierung. Viele Fehler in Python würde in C/C++ der Compiler als Typfehler melden und es nicht beim Aufruf eine Fehlermeldung geben. Python bringt aber nur eine Vorteil, wenn man nicht in Pointern, sondern abstrakten Objekten denkt. z.B. wenn ich prüfen möchte, ob ein Objekt in einer Liste ist schreibe ich in Python einfach
1 | if "myText" in Liste: |
Wenn man das stattdessen mit Iteratoren macht dann bringt Python natürlich keine Vorteil. Das erfordert aber ein Umdenken, wenn man aus der C Welt kommt.
Python läuft als MicroPython auch auf Microcontrollern!
osman schrieb: > Vor ein paar Jahren hörte > man überall Perl. Heute hört man davon nichts mehr. Heute hört man nur > noch Python. Warum? Was ist an Python so gut? weil es auch zur Kommunikation mit anderen Geräten taugt, so gibt es für den RasPi simple Routinen zur Ansteuerung der IO-Pins: https://www.raspberrypi.org/documentation/usage/gpio/python/README.md Perl ist irgendwie nie über den Gebrauch als Textparser hinausgekommen. Jupyter macht Python noch interessanter, Mit Python umfangreiche Signalanalyse wie FFT samt Visualisierung in einer scriptsprache runterkloppen uhnd gleich mit Interface zum FPGA: https://wiki.trenz-electronic.de/display/PD/TEI0023+-+Demo+ADC+data+acquisition+and+Fourier+transformation Wobei Jupyter mehr ist als nur python
Nick M. schrieb: > Ruby: Mitte 1990 > Perl: 1987 > Tcl: 1988 > PHP: 1995 > Python: Anfang 1990 > > Die liegen innerhalb eines Jahrzehnts und haben sich bis jetzt gehalten. Ja, aber auf sehr unterschiedlichen Rankings: https://www.informatik-aktuell.de/aktuelle-meldungen/2019/januar/tiobe-index-die-aktuellen-top-programmiersprachen-im-ranking.html Ich glaube nicht, das die genannten Python den dritten Platz streitig machen werden.
osman schrieb: > Was ist an Python so gut? Es ist eine einfach zu lernende Skriptsprache mit der man schnell zum Ziel kommt. Das macht sie für Einsteiger und Fortgeschrittene beidermaßen interessant.
osman schrieb: > Kann jemand erklären, was ist das besondere an der programmiersprache > Python? Nichts. Python scheint insgesamt für viele Anwender einfach gut zu funktionieren. Es gibt jede Menge Projekte, Bibliotheken, Frameworks. Nicht abschließende Aufzählung von typischen Merkmalen, aber wir können ja mal sammeln: W.S. schrieb: > Bei anderen Programmiersprachen dienen spezielle Wörter oder Zeichen zum > Kennzeichnen von Blöcken. > [...] > Und bei Python gibt es so etwas überhaupt nicht. Dort müssen Blöcke > durch Einrückungen gekennzeichnet werden. Das ist Teil eines größeren Plans, Konstrukte möglichst nahe an der natürlichen Sprache zu halten. In C und ähnlichen Sprachen würde es ungefähr heißen:
1 | for (int i = 0; i < max; i++) { ... |
... und dann benutzt man i z.B. für den Zugriff auf ein Array. Was die drei Blöcke in der Klammer bedeuten, muss man selbst wissen. Die Syntax gibt darauf keinerlei Hinweise. Python macht daraus ein einfaches:
1 | for abc in xyz: |
... wobei in den meisten Fällen die Iterationsvariable ganz wegfällt, weil xyz selbst eine iterierbare Klasse ist und "selbst weiß, wie man sich aufzählt", also nicht darauf angewiesen ist, dass du Abbruchbedingung oder ähnliches angibst. Ob das zu dem beabsichtigen hübschen Code führt, hängt ganz wesentlich vom Programmierer ab. Auch wenn es oft eine "richtige" Art gibt, Dinge zu tun, geht es meistens auch anders. Python ist nicht dogmatisch. Beispiele: - Es gibt Typisierung, aber keine deklarierten Typen. Typen werden nur erzwungen, wenn das der Kontext erfordert. Oder wenn der Programmierer das explizit erzwingt. - Es gibt Objektorientierung, aber für eigenen Code (also nicht für Bibliotheken) musst du sie nicht benutzen und kannst auch "einfach" imperativ programmieren. Oder komplett objektorientiert. Oder etwas dazwischen. - Es gibt eine Konvention für private Eigenschaften und Methoden einer Klasse, aber es gibt keinen strikten Mechanismus, der sie durchsetzt. Wenn du eine "private" Eigenschaft von außen ansprechen möchtest, hält dich niemand davon ab. - Es gibt eine Konvention für Konstanten, aber es gibt keine deklarierten Konstanten und wenn du sie unbedingt ändern willst ... Python hat ein paar elegante Datenstrukturen, insbesondere list, tuple und dictionary, die in der Praxis ganz gut funktionieren. Wer stark in Arrays denkt, hat damit am Anfang meistens ein bisschen Probleme, aber irgendwann fällt der Groschen. Nicht unbedingt für den Einsteiger geeignet, aber mit list comprehensions kann man sehr elegant Filterbedingungen ausdrücken. Andere funktionale Konstrukte (curry, lambda) gibt es auch. Python hat eine sehr gute Anbindung zu C (das liegt daran, wie Pyhton intern funktioniert) und damit eine hervorragende Unterstützung für alles, was es auch in C gibt. Auch mit anderen Sprachen und Schnittstellen kommt Python gut klar. Das ist u.a. bei Webanwendungen extrem praktisch, bei der Integration in bereits existierende Projekte und wenn Teilprobleme besser in anderen Sprachen lösbar sind. Python hat einen interaktiven Interpreter, in dem man mal schnell was ausprobieren kann. Vor allem die Introspektion glänzt hier. Paketmanager gibt's auch, aber das hat heute praktisch jeder. Python gibt es seit fast 30 Jahren. Wenn das überhaupt nichts taugen würde, wäre es schon längst in der Versenkung verschwunden. Es ist aber wie mit allen Sprachen: Nichts ist unersetzlich und was wir in 10 oder 20 Jahren einsetzen, weiß heute niemand.
osman schrieb: > Was ist an Python so gut? Das die Industrie neue schnellere Kisten verkaufen kann, damit Programme genauso schnell laufen wie ihre Pendants, die in C/C++/ASM programmiert wurden und auch auf Alt-Systemen so schon eine gute Performance erreichen.
just everything schrieb: > Ja, aber auf sehr unterschiedlichen Rankings: > https://www.informatik-aktuell.de/aktuelle-meldungen/2019/januar/tiobe-index-die-aktuellen-top-programmiersprachen-im-ranking.html > Ich glaube nicht, das die genannten Python den dritten Platz streitig > machen werden. Kann es sein, dass dort bei informatik-aktuell.de Perl und Pearl in einen Topf geworfen wird? https://de.wikipedia.org/wiki/PEARL
Besucher schrieb: > Python läuft als MicroPython auch auf Microcontrollern! Warum sollte man sich das antun? Oder warum sollte man das überhaupt machen? Weil man kein C kann?
was ist das besondere an der programmiersprache Python? ----- Das frage ich mich auch. Eine "Programmiersprache", die per wrapper-Funktionen mit richtigen Programmiersprachen kommuniziert und ihre Libs nutzt. Pfui Deibel.
Heiner schrieb: > Das ist Teil eines größeren Plans, Konstrukte möglichst nahe an der > natürlichen Sprache zu halten. Was direkt zu COBOL führt: ;-) SUBTRACT Fed-Tax From Total-Tax Giving Soc-Sec-Tax.
:
Bearbeitet durch User
nichts schrieb: > Eine "Programmiersprache", die per > wrapper-Funktionen mit richtigen Programmiersprachen kommuniziert und > ihre Libs nutzt. Pfui Deibel. M.a.W: Alle Programmiersprachen, deren Datentypen und Aufrufverfahren nicht mit den C Konventionen konform gehen, sind von Übel?
just everything schrieb: > Ja, aber auf sehr unterschiedlichen Rankings: Das ist so wie mit Microsoft-Produkten. :-)) Man sollte sichj aber auch noch den zeitlichen Verlauf ansehen. Da erkennt man schon, dass das in den letzten Jahren zugelegt hat. Ist aber eher egal, läuft nur auf einen language war raus. Ich lerne jetzt mal OCaml ...
Gegenfrage: Was bringt einem Delphi? Was bringt einem COBOL? Was bringt einem die Programmiersprache JAVA? Nun, bei letzterer haben wir eine extrem unsichere Basis, tausendfach geflickt, mittlerweile vielleicht nicht mehr ganz so extrem. Trotzdem extrem flexibel, kann ohne weitere Toolkits grafische Oberflächen darstellen und ist portabel. Es wird millionenfach an Schulen und Universitäten gelehrt. Darum ist es auch weit verbreitet. Wenn man es versteht, kann man unendlich viele Programme von anderen Lesen, verändern oder eigene Programme mit dem eigenen dort erworbenem Wissen erstellen. Bei Python verhält es sich ähnlich. Allerdings wird Python weniger für GUI Anwendungen benutzt, sondern für Programme auf der Konsole oder beispielsweise für die Programmierung von Plugins. Wer beispielsweise mit KiCAD Platinen erstellt, kann dafür Plugins benutzen, die in Python geschrieben sind oder selber welche erstellen. Ich persönlich mag Python auch nicht besonders, aber Perl finde ich schlimmer... So hat jedes Werkzeug eigene, spezielle Eigenschaften, die es für einen besonderen Zweck geeignet machen.
Hmmm schrieb: > Warum sollte man sich das antun? Oder warum sollte man das überhaupt > machen? Weil man kein C kann? Genau. So geschehen bei einem Vollpfosten bei mir in der Arbeit. Aber wenn man so schlau ist einen Router zu cracken damit man seine eigene SW installieren kann und dann die Zeitbombe an Kunden verkauft, wohl wissend, dass man kein Update mehr installieren kann ...
osman schrieb: > Kann jemand erklären, was ist das besondere an der programmiersprache > Python? [x] es ist nicht Perl [x] es ist nicht PHP [x] es ist nicht C [x] es ist nicht Java > Ich habe bisher keine Kenntnisse über Python. Vor ein paar Jahren hörte > man überall Perl. Heute hört man davon nichts mehr. Heute hört man nur > noch Python. Warum? Weil "man" (?) an komischen Stellen "hört"? Warum ist das wichtig, was man irgendwo hört? Programmiersprachen sind wie das Wetter. Oder (Damen-)Mode. Heute so, morgen so. Ich glaube ja, es liegt daran, das die RaspBerry Pi Erfinder Python toll fanden und es gepushed haben. Ansonsten ist das eine ganz normale Skriptsprache. Kennst du eine, kennst du alle. Es gäbe da auch noch Javascript. Oder Lua. Ruby. Such dir was aus. Manchmal hast du auch gar nicht besonders viel Auswahl. PS: da denkt man nichts Böses. Man denkt einfach nur "YASL!". Und dann ist da https://github.com/yasl-lang/yasl Das ist doch ein Witz! Bitte, das muß doch ein Witz sein!!1elf!
:
Bearbeitet durch User
Hmmm schrieb: > Besucher schrieb: >> Python läuft als MicroPython auch auf Microcontrollern! > > Warum sollte man sich das antun? Oder warum sollte man das überhaupt > machen? Weil man kein C kann? Weil der Stundenlohn des Pythonprogrammierer günstiger ist als der des C Programmierer und weil der Pythonprogrammierer aufgrund der Sprache schneller zum Ziel kommt. Beides spart Geld. Der Preis dafür ist eine höhere Leistungsanforderung an die Hardware. Jetzt kommt's also darauf an, wie hoch die Stückkosten sind. Produzierst du ein paar Millionen Stück davon, dann könnte es wichtiger sein am µC 3 Cent pro Stück zu sparen und die Software dann lieber in C zu entwickeln.
Gruss zur Nacht, am Morgen Ich hatte mich mal für eine Skriptsprache interessiert, probierte dann das anfängliche Python aus, viele Versprechungen, oh graus, da lief aber nichts. Ich nahm dann newLisp mit GUI und java(Server), das ging gut, möchte ich nicht missen. Aber nicht "direkt" mit einem Mikrocontroller. Dirk St
osman schrieb: > Kann jemand erklären, was ist das besondere an der programmiersprache > Python? > Ich habe bisher keine Kenntnisse über Python. Vor ein paar Jahren hörte > man überall Perl. Heute hört man davon nichts mehr. Heute hört man nur > noch Python. Warum? Was ist an Python so gut? Python legt einen besonderen Fokus aus Lesbarkeit und kompakten Code, ist besonders einfach zu erlernen (in Großbritannien wird es sogar schon an einigen Grundschulen gelehrt) und gleichzeitig durch seine umfangreiche interne und externe Infrastruktur an Paketen und Modulen ausgesprochen mächtig. Wo man sich bei anderen Sprachen seine Module zusammensuchen muß, um -- zum Beispiel -- CSV- oder JSON-Dateien lesen und parsen zu können, bringt Python bereits fertige Module mit. Obendrein ist Python sehr flexibel; die Sprache bietet eine hervorragende Anbindung an C und mit boost::python auch an C++ und kann in beiden Fällen sowohl als Gluesprache, als auch als interne Skriptsprache genutzt werden. Die Python-Interpreter in Java und .NET integrieren sich wunderbar in die jeweiligen Ökosysteme, und wer es besonders performant haben will, nimmt anstelle des Standard-Interpreters CPython einfach Pypy mit seinem JIT-Compiler. Und dann, wie gesagt, die Infrastruktur. Es gibt so ziemlich nichts, das sich nicht mit Python machen oder ansprechen läßt. Obendrein bringt Python sehr mächtige Pakete für Aufgaben der Datenverarbeitung, -analyse und -visualisierung, was dazu führt, daß es sowohl in der wissenschaftlichen Community, als auch bei den Data Scientists besonders beliebt ist. Wohl auch deswegen gibt es so ziemlich kein Framework in den Bereichen Distributed Computing, Machine Learning und Natural Language Processing, das nicht mit einer leistungsfähigen Python-Schnittstelle ausgestattet ist. Ich selbst hatte auch zuerst Vorbehalte gegenüber Python, gerade wegen der Sache mit dem Whitespace. Trotzdem habe ich festgestellt, daß eine Menge Projekte auf Python als Skriptsprache setzten, zum Beispiel OpenOffice.org, das K Desktop Environment, sowie PostgreSQL. Warum, habe ich mich gefragt, nutzen die ausgerechnet Python? Nun, ich habe mir dann irgendwann an einem lauschigen Winterabend mal einige kleinere Tutorials angeschaut und ein paar kleine Programme gebastelt, und... auf einmal war das mit dem Whitespace gar nicht schlimm, die Programme waren -- im Vergleich zu meiner damaligen Standard-Skriptsprache Perl -- viel schneller und stabiler, und die Fehlermeldungen wesentlich aussagekräftiger. Und, meine Güte, endlich mal eine gute Implementierung von Objektorientierung statt dem fiesen Gehassel in Perl5! Und heute? Nach deutlich über zehn Jahren mit Python bin ich immer noch verliebt. In all dieser Zeit habe ich es nicht ein einziges Mal geschafft, den Interpreter zum Absturz zu bringen. Sogar der Standard-Interpreter ist etwa doppelt so schnell wie Ruby, Pypy dagegen -- je nach Anwendungsfall -- nochmals deutlich schneller, über die Projekte und Jahre würde ich etwa Faktor sechs bis acht schätzen. Ich mache so ziemlich alles in Python: Numbercrunching, Datenanalyse und -visualisierung sowohl auf FatClients als auch im Web, Websoftware mit Flask, GUI-Software mit Tkinter/Tix und Qt, ... oft ist es sogar so, daß ich mir die Python-API einer Software ansehe, wenn sich deren eigene Dokumentation mir nicht erschließen will. Für mich ist der wesentliche Unterschied zwischen meiner alten Standardskriptsprache Perl und meiner neuen, Python: in Perl muß ich mir Mühe geben und sehr diszipliniert arbeiten, um saubere, les- und wartbare Programme zu schreiben. In Python muß ich mir Mühe geben und diszipliniert sein, um unlesbare Programme zu schreiben. Eine Geschichte, die der meinen ganz ähnlich zu sein scheint, ist übrigens die von Eric S. Raymond, besser bekannt als Autor von "The cathedral and the bazaar" und der Fetchmail-Software. Wie er sich in Python verliebt hat, beschreibt er hier: [1]. [1] https://www.linuxjournal.com/article/3882 PS: Es hat hier einige negative Äußerungen gegeben, die allerdings überwiegend zwei Eigenschaften haben: die Autoren haben offensichtlich nicht die geringste Erfahrung mit der Sprache, und ihre Ausführungen beschäftigen sich im Wesentlichen mit ihren engstirnigen Vorurteilen anstatt mit valider Kritik. Die einzige valide Kritik, die ich hier gelesen habe, ist die Sache mit dem Whitespace. Und ja, das kann hin und wieder genauso nerven wie die Klammerorgien anderer Sprachen, aber mit einem guten Editor (in meinem Falle dem GNU Emacs) ist das sehr gut beherrschbar. Andererseits ist gerade diese Eigenart einer der wichtigsten Gründe dafür, warum Python-Code so besonders gut les- und wartbar ist -- zusammen mit der Designentscheidung, auf krude syntaktische Konstrukte ("syntaktischen Zucker") weitestgehend zu verzichten. Hör' nicht auf die Meckerzicken und Miesmacher, sondern probier' Python einfach aus und mach Dir ein eigenes Bild davon. Aber bitte, benutz unbedingt einen guten Editor, der zumindest Syntax-Highlighting und automatische Einrückung unterstützt, richtig gute wie der Emacs können allerdings auch Autocompletion und mehr. Viel Spaß! ;-)
just everything schrieb: > Nick M. schrieb: > >> Ruby: Mitte 1990 >> Perl: 1987 >> Tcl: 1988 >> PHP: 1995 >> Python: Anfang 1990 >> >> Die liegen innerhalb eines Jahrzehnts und haben sich bis jetzt gehalten. > > Ja, aber auf sehr unterschiedlichen Rankings: > https://www.informatik-aktuell.de/aktuelle-meldungen/2019/januar/tiobe-index-die-aktuellen-top-programmiersprachen-im-ranking.html > Ich glaube nicht, das die genannten Python den dritten Platz streitig > machen werden. Naja, je nachdem, welchen Programmiersprachenindex man bemüht und wie diese ihre Daten und Rankings erheben, ist Python immer auf einem der Plätze 1 bis 3. Wobei man sagen muß, daß Python keine Konkurrenz zu kompilierten Sprachen wie C, C++ oder Java ist, sondern vielmehr eine Ergänzung -- oder umgekehrt, die kompilierten eine Ergänzung für eine leistungsfähige und moderne Skriptsprache ist, je nachdem aus welcher Perspektive man das konkret betrachten will. Aber bei den Skriptsprachen hat Python bereits seit geraumer Zeit in allen mir bekannten Indizes gewonnen. Hier im Thread hat jemand geschrieben, daß man nicht wissen könne, wie es in zehn oder zwanzig Jahren aussieht. Das ist natürlich einerseits richtig, vielleicht gibt es morgen eine enorme technische (R)Evolution, vielleicht verbocken die Entwickler von Python die nächste Version, oder womöglich entwickelt sich PHP sogar doch noch vom One-Trick-Web-Pony zu einer echten General-Purpose-Sprache. Aber wenn man sich die Entwicklung der beliebtesten Sprachen über die letzten Jahre ansieht, stellt man recht schnell fest, daß die Entwicklungen, Trends und Veränderungen hier ziemlich langsam vonstatten gehen. Und wenn man auf die Umfragen von Stackoverflow schaut, wo Python seit Jahren und immer noch am Häufigsten als "Most Wanted" genannt wird, wird schnell klar, daß der Siegeszug von Python wohl noch lange nicht gestoppt ist. Und das ist auch kein Hype, sondern eine Entwicklung, die sich seit sehr, sehr vielen Jahren und ausgesprochen stetig und stabil abzeichnet.
AtariST schrieb: > Allerdings wird Python weniger für GUI Anwendungen benutzt, > sondern für Programme auf der Konsole oder beispielsweise für die > Programmierung von Plugins. Wenn man sich die (sehr unvollständige) Liste von Python-Software bei Wikipedia [1] anschaut, stellt schnell fest, daß das nicht stimmt. Python wird sehr häufig auch für GUI-Software benutzt oder in GUI-Programme eingebettet, nur: der Anwender merkt davon meistens nichts, es werden dieselben Toolkits benutzt wie bei anderen GUIs. [1] https://en.wikipedia.org/wiki/List_of_Python_software
Bastelmumie schrieb: >> Was ist an Python so gut? > Python ist ungiftig. Beißt sich aber mit Squirrel-Mail. :)
Sheeva P. schrieb: > Das ist natürlich einerseits > richtig, vielleicht gibt es morgen eine enorme technische (R)Evolution, Rust im Bereich der compilierten Sprachen und der Systemprogrammierung. C und C++ wird es allerdings dennoch nicht eretzen, aber zumindest ergänzen und bei Neuentwicklungen dürfte es zunehmend öfters eingesetzt werden.
W.S. schrieb: > Ich halte das für gequirlten Irrsinn. Programmiersprachen sollen > gefälligst klar lesbare Zeichen/Worte haben, um damit Blöcke zu > kennzeichnen! Aber hier bei Python haben wir stattdessen > unterschiedliche Anzahl von 'white space' Zeichen! > > Und was passiert dort, wenn man 1x Space und dann 1x Tab schreibt? > Nein, nicht mit mir. Das wird immer wieder als das große "Problem" aufgetan. Irgendwie verstehe ich das nicht. Es erzwingt halt vernünftige Einrückung. Die mache ich sowieso, deshalb stört mich das auch nicht. Wenn du immer wie Kraut und Rüben einrückst (und auch noch munter Tabs und Spaces mischst), dann ist das natürlich was anderes. Das liegt dann aber an dir und nicht an der Sprache. Nick M. schrieb: > Also geht es um Interpretierte/Scriptsprachen. Jeder Softwareentwickler > muss eine Scriptsprache können. Das sehe ich auch so. Welche das ist, spielt eigentlich keine so große Rolle. Eine Sprache mit großer Verbreitung hat allerdings noch den Vorteil, dass man besonders viel darüber im Internet findet. > Python hab ich schon mal gehört. -) Brauch ich nicht, erscheint mir als Hmm, wenn man sich das anschaut: > Witzig ist, wann die Sprachen entwickelt wurden: > Ruby: Mitte 1990 > Perl: 1987 > Tcl: 1988 > PHP: 1995 > Python: Anfang 1990 Warum siehst du dann ausgerechnet Python als Hype an? Heiner schrieb: > In C und ähnlichen Sprachen würde es ungefähr heißen: > for (int i = 0; i < max; i++) { ... > ... und dann benutzt man i z.B. für den Zugriff auf ein Array. Was die > drei Blöcke in der Klammer bedeuten, muss man selbst wissen. Die Syntax > gibt darauf keinerlei Hinweise. Python macht daraus ein einfaches: > for abc in xyz: > ... wobei in den meisten Fällen die Iterationsvariable ganz wegfällt, > weil xyz selbst eine iterierbare Klasse ist und "selbst weiß, wie man > sich aufzählt", also nicht darauf angewiesen ist, dass du > Abbruchbedingung oder ähnliches angibst. Ob das zu dem beabsichtigen > hübschen Code führt, hängt ganz wesentlich vom Programmierer ab. Wobei C++ das ja in ähnlicher Form mit range-based for übernommen hat. Da kann man schreiben: for (auto abc: xyz) Axel S. schrieb: > Weil "man" (?) an komischen Stellen "hört"? Warum ist das wichtig, was > man irgendwo hört? Programmiersprachen sind wie das Wetter. Oder > (Damen-)Mode. Heute so, morgen so. Naja, zu einer fast 30 Jahre alten Sprache, deren Beliebtheit kontinuierlich steigt, passt diese Aussage nicht so ganz. > Ich glaube ja, es liegt daran, das die RaspBerry Pi Erfinder Python toll > fanden und es gepushed haben. Auch im KI-Bereich ist Python weit verbreitet. Sheeva P. schrieb: > Für mich ist der wesentliche Unterschied zwischen meiner alten > Standardskriptsprache Perl und meiner neuen, Python: in Perl muß ich mir > Mühe geben und sehr diszipliniert arbeiten, um saubere, les- und > wartbare Programme zu schreiben. In Python muß ich mir Mühe geben und > diszipliniert sein, um unlesbare Programme zu schreiben. Gut, Perl ist ja dafür verschrien, dass damit meist "write-only"-Code geschrieben wird. Allerdings tue ich mich in Python auch recht schwer damit, Code zu schreiben, den ich ein Jahr später wieder leicht verstehen kann und finde, dass man gerade dort besonders diszipliniert arbeiten muss, um lesbaren Code zu erhalten. Bei C++ gelingt es mir jedenfalls deutlich besser. Ich weiß aber nicht so genau, woran das liegt. Vielleicht daran, dass Python einfach zu viele Schweinereien erlaubt oder dass es nicht so streng typisiert ist.
Nano schrieb: > Sheeva P. schrieb: >> Das ist natürlich einerseits >> richtig, vielleicht gibt es morgen eine enorme technische (R)Evolution, > > Rust im Bereich der compilierten Sprachen und der Systemprogrammierung. > > C und C++ wird es allerdings dennoch nicht eretzen, aber zumindest > ergänzen und bei Neuentwicklungen dürfte es zunehmend öfters eingesetzt > werden. Einerseits sehe ich das (noch?) lange nicht, daß Rust eine größere Rolle spielt, im Moment scheint das Momentum eher bei Go zu liegen. Andererseits spielt Rust in einer Diskussion, in der es um die (meistens) interpretierte General-Purpose-Skriptsprache Python geht, wohl auch keine Rolle. Warum das "meistens"? Weil Python natürlich kompiliert werden kann, entweder in (interpretierten) Bytecode -- oder auch in nativen Maschinencode.
Rolf M. schrieb: > Sheeva P. schrieb: >> Für mich ist der wesentliche Unterschied zwischen meiner alten >> Standardskriptsprache Perl und meiner neuen, Python: in Perl muß ich mir >> Mühe geben und sehr diszipliniert arbeiten, um saubere, les- und >> wartbare Programme zu schreiben. In Python muß ich mir Mühe geben und >> diszipliniert sein, um unlesbare Programme zu schreiben. > > Gut, Perl ist ja dafür verschrien, dass damit meist "write-only"-Code > geschrieben wird. Allerdings tue ich mich in Python auch recht schwer > damit, Code zu schreiben, den ich ein Jahr später wieder leicht > verstehen kann und finde, dass man gerade dort besonders diszipliniert > arbeiten muss, um lesbaren Code zu erhalten. Bei C++ gelingt es mir > jedenfalls deutlich besser. Ich weiß aber nicht so genau, woran das > liegt. Vielleicht daran, dass Python einfach zu viele Schweinereien > erlaubt oder dass es nicht so streng typisiert ist. Vermutlich Übungssache, bei mir ist es nämlich genau andersherum. Aber ich schreibe jeden Tag etwas in Python und alle paar Wochen und manchmal auch Monate etwas in C++ -- wenn das bei Dir andersherum ist, könnte das die Ursache sein.
Sheeva P. schrieb: > Python legt einen besonderen Fokus aus Lesbarkeit und kompakten Code Wie gut eine Sprache lesbar ist liegt (fast) immer im Schreibstil des Authors. Ich kann auch in C/C++ wunderbar formatierten Code schreiben. Diese Tabs/Leerzeichen von Python finde ich z.B. grausam lesbar und irre schlecht wartbar. Jeder Profi den ich kenne lehnt Python als vollwertige Sprache ab, alleine aufgrund der Einrückungen. Natürlich kann man damit kurze Scripte schreiben, dafür reicht es. Aber ich würde niemals damit einen µC oder ein größeres Projekt umsetzen.
FFFFFFFF schrieb: > Sheeva P. schrieb: >> Python legt einen besonderen Fokus aus Lesbarkeit und kompakten Code > > Wie gut eine Sprache lesbar ist liegt (fast) immer im Schreibstil des > Authors. Ich kann auch in C/C++ wunderbar formatierten Code schreiben. Die Lesbarkeit von Code hängt allerdings nicht nur von der Formatierung ab. > Diese Tabs/Leerzeichen von Python finde ich z.B. grausam lesbar und irre > schlecht wartbar. Das ist, wie so vieles, reine Übungssache. Jedenfalls erzwingt diese Eigenschaft eine saubere Blockeinrückung, und mir ist unverständlich, wie das die Lesbarkeit verschlechtern sollte, das ist ja völlig abstrus. > Jeder Profi den ich kenne lehnt Python als vollwertige Sprache ab, > alleine aufgrund der Einrückungen. Dann kennst Du vielleicht die falschen "Profis". Ich selbst jedenfalls bin Profi und arbeite mit vielen Profis zusammen, und sogar die, die anfangs noch viel lieber Ruby haben wollten, finden Python mittlerweile toll. Es ist auch schon sehr merkwürdig, daß Python in der StackOverflow-Survey von 2020 bei den "Most Wanted" auf Platz 1 ist -- wie auch schon seit 2017 und mit weiterhin steigender Tendenz. Ähnliches gilt für die bekannten Programmiersprachenindices, Red Monk, PYPI und TIOBE: überall liegt Python ganz weit vorne. Ich weiß ja nicht, aber wenn die von mir befragten Profis alle so weit daneben liegen... also ich würde mir dann neue Profis zum Befragen suchen. > Natürlich kann man damit kurze Scripte schreiben, dafür reicht es. Wobei man natürlich dazu sagen muß, daß schon ein kurzes Python-Skript mindestens genau so viel Funktionalität hat, wie ein viele, viele Seiten langes Programm in C++, Java oder gar C. Aber man kann auch sehr gut längere Programme mit Python schreiben, das funktioniert ganz wunderbar -- zum Beispiel die Kollaborations- und Workflowmanagementsoftware TACTIC [1] mit knapp 200.000 LOC, die eventbasierte Netzwerkengine Twistet mit knapp 150.000 LOC, oder das Webframework Django und den OR-Mapper SqlAlchemy mit jeweils über 110.000 LOC. > Aber ich würde niemals damit einen µC oder ein größeres Projekt umsetzen. Wenn Du das wählen und entscheiden kannst, ist das ja Deine Sache und schön für Dich. Andere können und machen das -- und die meisten vollkommen freiwillig. Aber, ja, Pythons Natur als Skriptsprache, seine dynamische Typisierung und die Sache mit dem Whitespace polarisieren. Die ersten beiden Eigenschaften werden von den Verfechtern der Einzig Wahren Lehre (tm) der kompilierten, streng typisierten Sprachen abgelehnt, und die Sache mit dem Whitespace hat ja auch bei mir anfangs große Skepsis ausgelöst. Aber nachdem ich die Erfahrung gemacht habe, kann ich mit voller Überzeugung sagen: das ist nur eine Sache der Gewohnheit, mehr nicht. In der praktischen Nutzung ist das vollkommen irrelevant. [1] https://southpawtech.com/tactic-open-source/
Sheeva P. schrieb: > Es ist auch schon sehr merkwürdig, daß Python in der > StackOverflow-Survey von 2020 bei den "Most Wanted" auf Platz 1 ist -- > wie auch schon seit 2017 und mit weiterhin steigender Tendenz. Das ist mir auch ein Rätsel. WIrd halt von den ganzen Noobs gepusht und dass das im Zusammenhang mit Raspberry Pi so gehypt wurde. Mikrocontroller -> C/C++/demnächst R... mir ist der Name entfallen Desktop -> Java/C#/C++ Server -> Java/C/C++ Scripte -> Python Sheeva P. schrieb: > Die Lesbarkeit von Code hängt allerdings nicht nur von der Formatierung > ab. Doch, fast immer. Sheeva P. schrieb: > Das ist, wie so vieles, reine Übungssache. Jedenfalls erzwingt diese > Eigenschaft eine saubere Blockeinrückung, und mir ist unverständlich, > wie das die Lesbarkeit verschlechtern sollte, das ist ja völlig abstrus. Ach, jetzt soll ich eine furchtbare Formatierungseigenschaft üben, bis ich diese kann? Nein danke, haben doch fast alle anderen Programmiersprachen etwas Klammern artiges - und das ist auch gut so liebe Genossinnen und Genossen. Auch ich habe schon Python verwenden müssen. Eine Katastrophe. In C/C++ kann ich praktisch wie wild drauf los schreiben. Natürlich gebe ich mir da schon etwas Mühe - am Ende jage ich einen Formatter drüber und gut ist. Bei Python eine Einrückung vergessen? Pech gehabt, stundenlange Fehlersuche. Ganz abgesehen davon muss nicht jeder Hinz und Kunz in meinem Programmcode rumfuhrwerken (es sei denn es ist openSOurce). Und die Ausführgeschwindigkeit kommt noch oben drauf. Ich sehe keinen praktischen Grund auf einem mikrocontroller python einzusetzen., bitte nenne mir einen. Hardwareabstraktion? Man sollte seinen µC kennen und das Manual + Registerebene verstanden haben - dann braucht man keine Hardwareabstraktion mehr. lwip, freeRTOS - gibts das in python? Weiß ich nicht, das aber dann C mit Python auf einem µC koppeln ist wie mit Atomwaffen auf Spatzen zu schießen. Sheeva P. schrieb: > Andere können und machen das -- und die meisten > vollkommen freiwillig. Die tun mir auch wirklich leid. Wenn ich im professionellen Umfeld mit micropython kommen würde, wäre ich bald arbeitslos - so finde ich auf gängigen Jobportalen kein einziges Stellenangebot wenn ich danach suche. Ganz abgesehen davon, dass ich in C automatisch hardware nah denke - das hat schon Linus gesagt und recht hat er. Wenn µC irgendwann mal per standard im GHz Bereich sind können wir nochmal über µPython reden. Für die openSOurce Community ganz nett, für ernsthafte Entwicklung eher drittrangig.
:
Bearbeitet durch User
Ben S. schrieb: > Bei Python eine Einrückung vergessen? Pech gehabt, stundenlange > Fehlersuche. Bei C/C++ eine Klammer falsch gesetzt? Pech gehabt, stundenlange Fehlersuche. >Für die openSOurce Community ganz nett, für ernsthafte Entwicklung eher drittrangig. Irgendwie hört sich das an, als ob aus openSOurce keine ernsthaften Entwicklungen entstehen..... In diesem Forum ist man wahnsinnig schnell polemisch. Keiner zwingt einen zu einer Programmiersprache. Ich nutze verschiedene. Hab jahrzentelang Klammern gesetzt. Das Einrücken in Python war am Anfang ungewohnt aber nach wenigen Übungen in Fleisch und Blut übergegangen. Meine bisherigen Python Softwarefehler hatte nie damit zu tun, dass ich falsch eingerückt hatte. Ein Aspekt der bisher nicht genannt wurde: Ich nutze statt Matlab nur noch Python (meist über Jupyter Notebooks). Gerade für wissenschaftliche Berechnungen bietet die Sprache viel.
:
Bearbeitet durch User
Klaus H. schrieb: > Ben S. schrieb: >> Bei Python eine Einrückung vergessen? Pech gehabt, stundenlange >> Fehlersuche. > > Bei C/C++ eine Klammer falsch gesetzt? Pech gehabt, stundenlange > Fehlersuche. Dann formatierst du deinen Code nicht ordentlich...
Klaus H. schrieb: > Keiner zwingt einen zu einer Programmiersprache. Das soll bei professioneller Entwicklung in Unternehmen schon mal als Nebeneffekt der Berufs- und Arbeitsplatzwahl vorkommen.
Klaus H. schrieb: > Bei C/C++ eine Klammer falsch gesetzt? Pech gehabt, stundenlange > Fehlersuche. Eine Klammer kann ich hingegen nicht vergessen. Ne' Einrückung schon.
Ben S. schrieb: > Eine Klammer kann ich hingegen nicht vergessen. Ne' Einrückung schon. gequirlte Scheisse. Ein Programmierer, der nicht weiss, auf welcher Ebene in seinem Programm er sich bewegt, hat keine Ahnung. Und die Ebene gibt die Einrückung vor. Eine Klammer kann ich vergessen und dann fängt die Suche an, wo die vergessen wurde.
//.|.\\ schrieb: > Eine Klammer kann ich vergessen und dann fängt > die Suche an, wo die vergessen wurde. gequirlte scheisse. Die fehlende Klammer erzeugt eine Fehlermeldung. Die letzte Zeile eines Ifs in python nicht eingerückt ergibt keine Fehlermeldung 🙄.
:
Bearbeitet durch User
Aktiv Unsinn machen ist eigentlich in keiner Programmiersprache besonders schwer.
Beides Fehler, die einem eine ordentliche Entwicklungsumgebung zeigen sollte. Messdaten können mit Python super einfach aufbearbeitet werden, zusammen mit Jupyter kann man direkt eine präsentable Seite vorweisen.
Typ schrieb: > Messdaten können mit Python super einfach aufbearbeitet werden, zusammen > mit Jupyter kann man direkt eine präsentable Seite vorweisen. Das ist auch ein guter Anwendungszweck von Python: Verarbeitung von wissenschaftlichen Daten. Aber in der Desktop/Server/µC-Programmierung für mich ein nogo - höchstens für kleine Testtools oder so. Aufm raspberry für die, die kein C/C++ können. Walter T. schrieb: > Aktiv Unsinn machen ist eigentlich in keiner Programmiersprache > besonders schwer. Ein tab/Klammer kann auch mal durch Unachtsamkeit verloren gehen.
:
Bearbeitet durch User
Walter T. schrieb: > Aktiv Unsinn machen ist eigentlich in keiner Programmiersprache > besonders schwer. Passiv auch. Der subtile Unterschied zwischen { und ( erschliesst sich bei ungeeigneten Fonts und hochauflösenden Bildschirmen optisch nicht immer sofort. Einrückung ist schwerer zu übersehen.
Typ schrieb: > Messdaten können mit Python super einfach aufbearbeitet werden, zusammen > mit Jupyter kann man direkt eine präsentable Seite vorweisen. Reportgenerierung ist der Ursprung von Perl. Sowas kann mit Schriptsprachen viel einfacher sein als mit C/C++.
Ich werde auch immer mehr zum Python-Benutzer im Scriptingbereich. Die Vorteile wurden ja schon alle genannt. Die schnellste Interpreter-Sprache ist es sicher nicht, aber dank der vielfältigen Module sehr mächtig und imallgemeinen gut zu lesen, natürlich kann man auch in Python Konstrukte bauen die schwer zu verstehen sind. Einschränkungen gibt es leider für "One-Liner", also kleine Einzeiler-Scripte für die Benutzung auf der Shell. Das geht mit perl und awk relativ gut, mit Python geht es aufgrund der notwendigen Einrückungen nur mit großen Einschränkungen, oder findet jemand das übersichtlich?
1 | aws ec2 describe-instances | python3 -c 'import json; import sys; import re; d = json.load(sys.stdin); [[[print(i["InstanceId"]) for t in i["Tags"] if t["Key"] == "Name" and re.search("mein_regex", t["Value"], flags=re.I) ] for i in x["Instances"]] for x in d["Reservations"]]'
|
(ja, man hätte wahrscheinlich jq nehmen können, mein Problem mit jq ist, dass die Syntax beim Versuch es zu verstehen regelmäßig mein Hirn sprengt, die awscli Optionen --filter und --query sind leider beide case-sensitive). Was die fehlende Typisierung angeht gibt es Abhilfe: https://docs.python.org/3/library/typing.html
Ben S. schrieb: > gequirlte scheisse. Die fehlende Klammer erzeugt eine Fehlermeldung. Und woher weiss der Compiler, wo die Klammer hinsoll ???
Sheeva P. schrieb: > AtariST schrieb: >> Allerdings wird Python weniger für GUI Anwendungen benutzt, >> sondern für Programme auf der Konsole oder beispielsweise für die >> Programmierung von Plugins. > > Wenn man sich die (sehr unvollständige) Liste von Python-Software bei > Wikipedia [1] anschaut, stellt schnell fest, daß das nicht stimmt. > Python wird sehr häufig auch für GUI-Software benutzt oder in > GUI-Programme eingebettet, nur: der Anwender merkt davon meistens > nichts, es werden dieselben Toolkits benutzt wie bei anderen GUIs. > > [1] https://en.wikipedia.org/wiki/List_of_Python_software Natürlich! Ich habe ja auch nicht behauptet, dass es das nicht gäbe, der Anteil der allein in Python geschriebenen Programme mit GUI ist im Verhältnis zu in anderen Programmiersprachen geschriebenen Programmen aber relativ gering. Wer C beherrscht, kann in C grafische Oberflächen auch nicht ohne Toolkit, wie z.B. GTK erstellen. Wie bereits geschrieben, für jeden Zweck gibt es ein passendes Werkzeug, manchmal ist es halt etwas umständlich zu bedienen. Man nutzt das, was man beherrscht, und das ist in vielen Fällen eben Java (fast jede Android-Anwendung ist in Java geschrieben). Wer z.B. Plugins für eine Vielzahl von Programmen schreiben will, ist mit Python meist gut bedient. Soll jetzt aber kein Flamewar werden, sondern eine reine Feststellung.
Ben S. schrieb: > Ein tab/Klammer kann auch mal durch Unachtsamkeit verloren gehen. Und wenn man sich daran gewöhnt hat, dass die Formatierung Teil der Programmiersprache ist, sorgt man dafür, dass das nicht zu einem Problem wird. Zum Beispiel durch den strategisch sinnvollen Einsatz von Leerzeilen.
Python ist perfekt für die kleine Skript-Aufgabe zwischendurch. Für große Rechenaufgaben nimmt man effiziente Programmiersprachen wie Matlab und Fortran.
:
Bearbeitet durch User
Ja, woher nimmt man dann Matlab? Wer ist bereit soviel Geld privat zu bezahlen? Da ist Python in der Tat eine sehr gute Alternative.
OK, jetzt hat also jeder verstanden, dass Python Einrückungen fehleranfällig sind. Und dass die Paarung der Klammerung in C/C++... der Fehler eines einzelnen fehlenden Zeichens erkannt wird (leider meist durch seltsame Fehlermeldungen.). Wie sieht es denn mit anderen Besonderheiten aus? Hat Python mehr/weniger Fälle von undefined behavoir / unspecified behavior als C / C++?
Klaus schrieb: > Wie sieht es denn mit anderen Besonderheiten aus? > Hat Python mehr/weniger Fälle von undefined behavoir / unspecified > behavior als C / C++? Nein, weil ein Interpreter würfelt genauso wenig wie ein Compiler. Was da als 'undefined behavoir' gebrandmarkt wird ist in Wirklichkit nur die Faulheit des Anwender das Manual oder ggf den Source zu lesen.
//.|.\\ schrieb: > Und woher weiss der Compiler, wo die Klammer hinsoll ??? Ich rede von einer fehlenden Klammer. Da kriegste immerhin eine Fehlermeldung. Bei einer fehlenden / falsch gesetzten Einrückumg bekommst im Zweifelsfall gar keine Fehlermeldung.
Beitrag #6489592 wurde von einem Moderator gelöscht.
Sheeva P. schrieb: > PS: Es hat hier einige negative Äußerungen gegeben, die allerdings > überwiegend zwei Eigenschaften haben: die Autoren haben offensichtlich > nicht die geringste Erfahrung mit der Sprache genau wie viele C&P Programmierer die dann Hilfe suchen weil: Sheeva P. schrieb: > Die einzige valide Kritik, die ich hier > gelesen habe, ist die Sache mit dem Whitespace. Und ja, das kann hin und > wieder genauso nerven wie die Klammerorgien anderer Sprachen und das ist es wenn Code irgendwie kopiert wird, {} ist immer eindeutig, whitespaces bleiben egal ein Block ist klar zu erkennen.
Ben S. schrieb: > Bei einer fehlenden / falsch gesetzten Einrückumg > bekommst im Zweifelsfall gar keine Fehlermeldung. Der Trick besteht darin, im Editor einen Monospace-Font und einen Tab mit einer mehr als 1 Zeichen Breite einzustellen. Dann ist das Problem deutlich schwerer zu übersehen als eine Klammer. Wenn man seinen Quelltext in Word mit der Schriftart Comic Sans MS schreibt, wird der vergessene Tab natürlich unter Umständen zum Problem, weil er genauso klein wie eine Klammer ist. Das ist aber dann einfach das falsche Werkzeug für den Anwendungsfall. Ich bin über die Einrück-Lösung auch nicht maximal glücklich. Aber es ist nicht so, als wäre das alles dadurch praktisch unbrauchbar. Warum jammern bei make eigentlich nicht alle über die Tabs? Oder liegt das einfach daran, dass make eher für schlaue Leute gedacht ist?
:
Bearbeitet durch User
Hallo, Walter T. schrieb: > Warum jammern bei make eigentlich nicht alle über die Tabs? Ich fand schon immer die Entscheidung, das die Quelltextformatierung Teil der Syntax b.z.w. Semantik ist schlecht. Bei (altem) Fortran oder make mag das ja noch historisch begründbar sein, aber modernen Sprachen wie Python (Entstehungsjahr 1991) sollte das eigentlich keine Spracheigenschaft mehr sein. rhf
Roland F. schrieb: > aber modernen Sprachen > wie Python (Entstehungsjahr 1991) sollte das eigentlich keine > Spracheigenschaft mehr sein. Gut auf den Punkt gebracht. Filter schrieb im Beitrag #6489592: > Python ist super für schnelles Prototyping. Wenn Laufzeit wichtig ist > eher Matlab oder C++. Und anschließend darf man den gesamten protogetypten Code auf C++ umschreiben? Naja ...
:
Bearbeitet durch User
Nick M. schrieb: > Hmmm schrieb: >> Warum sollte man sich das antun? Oder warum sollte man das überhaupt >> machen? Weil man kein C kann? > > Genau. So geschehen bei einem Vollpfosten bei mir in der Arbeit. > Aber wenn man so schlau ist einen Router zu cracken damit man seine > eigene SW installieren kann und dann die Zeitbombe an Kunden verkauft, > wohl wissend, dass man kein Update mehr installieren kann ... Was das mit Python zu tun haben soll bleibt im dunkeln.
Wodjanoi schrieb: > Nein, weil ein Interpreter würfelt genauso wenig wie ein Compiler. Was > da als 'undefined behavoir' gebrandmarkt wird ist in Wirklichkit nur die > Faulheit des Anwender das Manual oder ggf den Source zu lesen. Wirklich? Es gibt den Begriff undefined behavior in C/C++. ISO/IEC 14882:2003(E): Programming Languages - C++ §1.3.12 undefined behavior Das sollte eine ernste Frage sein. (Ich arbeite mit C/C++ und Python, jede Sprache hat Vor- und Nachteile). Für C/C++ wurde eine Zusammenfassung von undefined behavior gemacht. Gibt es das auch für Python? Über die Suche habe ich zwar einzelne undefined behavior Punkte gefunden, aber keine Zusammenfassung.
Walter T. schrieb: > effiziente Programmiersprachen wie Matlab Hast du mal einen Performanceǘerglich von Matlab und NumPy gemach? Ich glaube nicht, dass da Matlab signifikant besser ist.
Roland F. schrieb: > Bei (altem) Fortran oder > make mag das ja noch historisch begründbar sein, aber modernen Sprachen > wie Python (Entstehungsjahr 1991) sollte das eigentlich keine > Spracheigenschaft mehr sein. Mit welcher Begründung (die über ein will ich nicht oder kann ich nicht hinaus geht)? Oder pflegst du einen Programmierstil bei dem man in Python erst weit nach rechts scrollen muss, bis der erste Code erscheint?
Klaus schrieb: > Wodjanoi schrieb: >> Nein, weil ein Interpreter würfelt genauso wenig wie ein Compiler. Was >> da als 'undefined behavoir' gebrandmarkt wird ist in Wirklichkit nur die >> Faulheit des Anwender das Manual oder ggf den Source zu lesen. > > Wirklich? Es gibt den Begriff undefined behavior in C/C++. > ISO/IEC 14882:2003(E): Programming Languages - C++ §1.3.12 undefined > behavior > > Das sollte eine ernste Frage sein. Und das ist eine ernsthafte Anwort - ein Compiler würfelt nicht. Der Source definiert immer einen eindeutigen Compileroutput. Natürlich können zwei verschiedene Compiler (anderer Hersteller, Revisionen) unterschiedliche Outputs erzeugen. Vielleicht ein plus von Python das weniger Interpreter-Hersteller und -varianten kennt als C in seiner fast 48-jährigen Geschichte. >Ich fand schon immer die Entscheidung, das die Quelltextformatierung >Teil der Syntax b.z.w. Semantik ist schlecht. Und ich finde es es gut, wenn 'die Coder' zur Abfertigungn eines wenigsten minimal strukturierten Quelltextes mit daraus resultierender verbesserter Lesbarkeit für Menschen gezwungen sind. C erlaubt zuviel "Katzenpolka auf der Tastatur", bspw:
1 | for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("| "+(*u/4)%2); |
Wodjanoi schrieb: > C erlaubt zuviel "Katzenpolka auf der Tastatur", bspw: > for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("| "+(*u/4)%2); Vielleicht einfach mal clang-format installieren? Wenn jemand so seinen Quelltexte formatiert, dann ist es sein Problem (oder ausdrücklicher Wunsch). Bei mir wird der gleiche Quelltext dann automatisch so formatiert, wie ich es gern habe.
Wodjanoi schrieb: > Und das ist eine ernsthafte Anwort - ein Compiler würfelt nicht. Der > Source definiert immer einen eindeutigen Compileroutput. Das gilt zwar auch für UB bei C/C++, aber was der Compiler dabei produziert, ist nicht definiert (definiert in dem SInne, daß jemand anders als der Compilerbauer das vorhersagen könnte). Oliver
was ist ein eindeutiger Compileroutput? Kann das auch eine Fehlermeldung sein? Irgendwie finde ich diese nicht immer eindeutig.
gar kein problem schrieb: > Wenn jemand so seinen Quelltexte formatiert, dann ist es sein Problem > (oder ausdrücklicher Wunsch). Nein die dritten, die diesen alienhaften Fremdcode debuggen/erweitern müssen haben ein Problem damit, das der Coder solch ein Radebrech als 'wünschenswert' ansieht. >Bei mir wird der gleiche Quelltext dann > automatisch so formatiert, wie ich es gern habe. Du sollst aber keinen Code zum individuellen 'Gern haben' verfassen oder verformatieren, sondern gut les- und wartbaren. Das ist für Community-gepflegten 'Open Source' unerläßlich. Daher ist es ein interessanter Ansatz das manche Sprachdefinitionen extra Konstrukte enthalten um die masochistische oder sadistische Neigung mancher Coder bewußt zu lenken/begrenzen. Formatierung/Codestil ist kein Selbstzweck.
Wodjanoi schrieb: > Und das ist eine ernsthafte Anwort - ein Compiler würfelt nicht. Der > Source definiert immer einen eindeutigen Compileroutput. Das wird jetzt spitzfindig. Fakt: undefined behaviour wird in den Standards genutzt. Kennst Du alle? Hast Du das Kapitel gelesen? Inklusive der implementation defined behaviors? > Ein Compiler würfelt nicht OK, so kann man es sagen. Aber das Ergebnis kann gewürfelt sein. So mir passiert, weil das Verhalten eines Codeteiles plötzlich abhängig wurde von zufälligen Werten in Registern. Ich will nicht C angreifen, ich nutze es ja, auch gerne und kenne die Schwachstellen. Meine Frage war, ob jemand eine Übersicht der Schwachstellen (undefined behaviour) in Python kennt.
gar kein problem schrieb: > as ist ein eindeutiger Compileroutput? Das binary/executable das der Compiler/linker erzeugt. > Kann das auch eine Fehlermeldung > sein? Irgendwie finde ich diese nicht immer eindeutig. Du verwechselst Verständlichkeit mit eindeutigkeit. Für den Compiler ist es schon eindeutig klar, das er diesen Input nur mit dieser Error-meldung zu quittieren hat, auch wenn es für Dich nicht verständlich sein sollte, das Mama's Liebling da einen Fehler gebaut hat. ;-)
Wodjanoi schrieb: > sondern gut les- und wartbaren. Das ist für > Community-gepflegten 'Open Source' unerläßlich. Dann soll diese Community ihre Files mit clang-format und Co. einheitlich formatiern. Und erst dann zum Download anbieten. Das ist doch besser und sicherer wenn ein Programm das automatisch macht und nicht die Programmierer selbst.
Klaus schrieb: > Fakt: undefined behaviour wird in den Standards genutzt. > Kennst Du alle? Hast Du das Kapitel gelesen? > Inklusive der implementation defined behaviors? Ja ich hab genug gelesen um zu wissen was damit gemeint ist, der Einfluß von verschiedenen Sprachkonformen Compilerimplementierungen und ausführender Hardware >> Ein Compiler würfelt nicht >Aber das Ergebnis kann gewürfelt sein. >So mir passiert, weil das Verhalten eines Codeteiles plötzlich abhängig >wurde von zufälligen Werten in Registern. Das ist keine spontane Abhängigkeit, das ist ein unsauberer/unportierbarer/hardwareabhängiger Programm. Und dafür zeichnet der Programmierer verantwortlich, das er keine definierten Startbedingungen (initialisierung der Registervariable) garantiert hat. >Meine Frage war, ob jemand eine Übersicht der Schwachstellen (undefined >behaviour) in Python kennt. Die Schwäche liegt eher beim Coder der nicht begriffen hat, wie eine CPU funktioniert und das man nur dann definierte Ergebnisse erwarten kann, wenn alle Anfangsgrößen definiert aka initialisiert sind.
Karl schrieb: > Hast du mal einen Performanceǘerglich von Matlab und NumPy gemach? Ich > glaube nicht, dass da Matlab signifikant besser ist. Ich jetzt nicht. In der Uni hat mal jemand nen Vortrag halten sollen über den Performancegewinn von Vectorisierten Berechnungen gegenüber per For-Schleife. Das Ende vom Lied war, die neue Matlab Version hat die For-Schleife selber erkannt und war fast genauso schnell. Ich vermute mal, dass sich Vektorrechnungen in Numpy performancemäßig kaum von Matlab unterscheiden. Aber wenn du ne Python-For über Numpy Arrays machst, ist das sicherlich deutlich langsamer als alles, was du in Matlab machst. ... Hmm pypy unterstützt inzwischen Numpy oder? Das könnte auch schnell sein. Aber Numpy ist ja wahrscheinlich dennoch ne externe Bibliothek und so... Also mit pypy will ich mal keine Aussage treffen.
Karl schrieb: > Hast du mal einen Performanceǘerglich von Matlab und NumPy gemach? Ich > glaube nicht, dass da Matlab signifikant besser ist. Ja, aber nur bei kleinen Gleichungssystemen ( < 100000 Freiheitsgrade). Der Unterschied war sehr, sehr deutlich. Da reden wir von < 3 Minuten (damals war der Corei7 nagelneu) vs. "ich habe es irgendwann abgebrochen". Zumindest bei sparse-Matrizen mit ausgeprägter Bandstruktur ist Lapack/Scalapack ein Traum. Inwieweit mit Python verteiltes Rechnen auf mehreren Kernen geht, habe ich dann nicht mehr ausprobiert.
Roland F. schrieb: > Bei (altem) Fortran oder > make mag das ja noch historisch begründbar sein Den Lochkarten wars egal, wo das Loch sass. Und zumindest IBMs Mainframes hatten bei Textfiles keinen Zeilenseparator, sondern Zeilen fester Länge (typ 80) und ohnehin keine eincodierten TABs.
Ich hab mit Python noch nicht viel und mit numpy noch gar nichts gemacht, nur der Hinweis: Von <3Min auf "ich habs irgendwann abgebrochen" bin ich auch mit Matlab alleine schon gekommen. Klassiker: Statt Matrizenrechnung in zwei verschachtelten for-Schleife durch die Matrizen iterieren. Das Tool heißt nicht umsonst MATrix LABoratory. Vermutlich gibt es bei numpy ähnliche Fallstricke. Das nur, um einen einzelnen Datenpunkt einzuordnen. MfG, ARno
Arno schrieb: > Vermutlich gibt es bei numpy ähnliche Fallstricke. Deswegen lässt man jemanden das machen, der sich damit auskennt. Ich mag Python. Ich mag auch numpy. Das Preis-Leistungs-Verhältnis ist grandios. Aber für number crunching scheint es nicht gemacht.
Python ist so eine Art QuickBASIC der "Neuzeit". Leicht zu verstehen, leicht anzuwenden. Es hat sich wohl vor allem an Unis eingebürgert. Auch informatikferne Studenten können schnell den Umgang damit lernen. Oft ist es wohl so, dass die eigentlichen Funktionen oder Routinen in C++ oder anderen "schwierigen", aber schnellen Sprachen programmiert sind und der User von Python aus darauf zugreift.
Wodjanoi schrieb: > Das ist keine spontane Abhängigkeit, das ist ein > unsauberer/unportierbarer/hardwareabhängiger Programm. Und dafür > zeichnet der Programmierer verantwortlich, das er keine definierten > Startbedingungen (initialisierung der Registervariable) garantiert hat. Ich habe gültigen Code geschrieben. Der Sprachstandard und der Compiler haben daraus undefiniertes Verhalten gemacht. Ohne dieses Verhalten wäre alles OK gewesen. Es hätte keine nicht initialisierte Variable gegeben. Aber du hast Recht: ich war zu blöd zu sehen, dass hier ein UB vorliegt. Schon Lustig, man driftet immer vom Thema ab. Eigentlich ging es mir ja um UB bei Python.
Dann nochmal komplett, weil einige den Context verloren haben: Hmmm schrieb: > Besucher schrieb: >> Python läuft als MicroPython auch auf Microcontrollern! > > Warum sollte man sich das antun? Oder warum sollte man das überhaupt > machen? Weil man kein C kann? Meine Antwort darauf, ergänzt um das Stichwort MicroPython. > Genau. So geschehen bei einem Vollpfosten bei mir in der Arbeit. > Aber wenn man so schlau ist einen Router zu cracken damit man MicroPython und > seine > eigene SW installieren kann und dann die Zeitbombe an Kunden verkauft, > wohl wissend, dass man kein Update mehr installieren kann ...
W.S. schrieb: > Aber hier bei Python haben wir stattdessen > unterschiedliche Anzahl von 'white space' Zeichen! > > Und was passiert dort, wenn man 1x Space und dann 1x Tab schreibt? > Nein, nicht mit mir. Das ist ja wirklich übel. Ich stelle mir da die Fehlersuche sehr kompliziert vor. Mir war nicht klar, dass es noch moderne Programmiersprachen mit nennenswerter Verbreitung dieser Art gibt.
Hans schrieb: > Das ist ja wirklich übel. Ich stelle mir da die Fehlersuche sehr > kompliziert vor. Vor allem, wenn man zur Fehlersuche ein Stück code oder einen Test einfügt und man dazu neu formatieren muss. Und danach den test-code löschen und wieder neu formatieren. Brilliant! Ich pflege meinen Testcode linksbündig zu schreiben, weil ich den schneller finde und er sowieso den Tag nicht überleben wird.
Nick M. schrieb: > Hans schrieb: >> Das ist ja wirklich übel. Ich stelle mir da die Fehlersuche sehr >> kompliziert vor. > > Vor allem, wenn man zur Fehlersuche ein Stück code oder einen Test > einfügt und man dazu neu formatieren muss. Und danach den test-code > löschen und wieder neu formatieren. Brilliant! > Ich pflege meinen Testcode linksbündig zu schreiben, weil ich den > schneller finde und er sowieso den Tag nicht überleben wird. Man kann auch nicht mal eben einen Codefetzen hin- und her kopieren oder aus dem Netz übernehmen. Zwar bieten viele IDEs und Texteditoren einfache Mittel zur Steuerung der Einrückung, ich halte es aber für fragwürdig zwingend eine sauber eingerichtete IDE/Editor und die Kenntnis deren Kniffe und Shortcuts vorauszusetzen. Von dem Thema Whitespaces abgesehen gefällt mir Python ganz gut. Man kriegt in wenigen Zeilen enorm viel Funktionalität reingequetscht, die Sprache bietet viel syntaktischen Zucker für das Handling von Containern etc. Python ist ein wunderbares Werkzeug um mal eben was zu skripten oder zu automatisieren. Bei größeren Projekten stört mich die fehlende Typisierung sowie dass jeder auf so gut wie alles zugreifen kann. Das kann man zwar mit Disziplin und guter SW-Planung einigermaßen ausgleichen, es beißt sich aber m.M.n. mit dem Whitespace-Konzept wo (Formatierungs-)Diszplin explizit erzwungen wird. Ja was denn nun? Freiheiten oder Zwang zum sauberen Arbeiten? Aber bei meinen Bastelskripten störts mich nicht, da bin ich froh um die Freiheiten (die man in C paradoxerweise zurecht kritisiert). Qt macht mit Python definitiv mehr Spaß als mit C++ ;-)
:
Bearbeitet durch User
Beitrag #6489983 wurde von einem Moderator gelöscht.
Arno Dübel schrieb im Beitrag #6489983:
> ich sauf mir jetzt ein
Wenn man nix anderes kann ...
Nick M. schrieb: > Arno Dübel schrieb: >> ich sauf mir jetzt ein > > Wenn man nix anderes kann ... Auch das will gelernt sein. Hast du schon mal nen Anfänger saufen sehen? Schrecklich!
Le X. schrieb: > Von dem Thema Whitespaces abgesehen gefällt mir > Python ganz gut. Man kriegt in wenigen Zeilen > enorm viel Funktionalität reingequetscht, [...] Das gilt aber für andere Scriptsprachen auch (z.B. Tcl); das erklärt also nicht, warum ausgerechent Python so beliebt ist... > Bei größeren Projekten stört mich die fehlende > Typisierung sowie dass jeder auf so gut wie alles > zugreifen kann. Das geht mir witzigerweise bei Tcl genauso...
Ich finde Python ganz ok, dafür dass es nichts kostet und doch ganz schön mächtig ist. Manche Konstrukte sind schon ganz schön unlogisch und die fehlende Typisierung gefällt mir nicht. Mega grottig ist die "GUI-Fähigkeit" die ist auf dem Niveau von 1988. Wenn ich das mit VisualBasic aus den 1990ern vergleiche, war das damals besser gelöst. Nur: damals gab es halbwegs genormte Monitore. Heute muss eine GUI dynamisch skalieren. Da kann es nicht sein, dass Buttons und andere Grafikelemente per Pixel positioniert und definiert werden und das Look and Feel des Betriebssystem nicht wiederspiegelt.
DoS schrieb: > Mega grottig ist die "GUI-Fähigkeit" die ist auf > dem Niveau von 1988. ??? Du redest nicht etwa von "Tk"? Das ist nicht Python-spezifisch. > Wenn ich das mit VisualBasic aus den 1990ern vergleiche, > war das damals besser gelöst. Komisch. Von VisualBasic für Linux habe ich nie etwas gehört...
Ich bin ja auch eher Fan von C/C# (allerdings auch kein Profi) aber Python hat schon seine Berechtigung, auch wenn das manche hier nicht in den Hals bekommen, die würden am liebsten alles außer ASM und evtl. C verbieten. Es ist vorallem interessant für Leute die zwar keine Tech-Noobs sind allerdings auch keine Informatiker, also andere Ingenieure und Wissenschaftler. Deshalb gibt es eben eine Menge an bereits vorhandener Software und unterstüzung für Schnittstellen, wie zB. GPIB usw. Python ist sehr geeignet für die ganze "Zwischendurch-SW" also zB. Daten von Messgeräten/IO-Karten/Netzwerk einlesen und damit Berechnungen durchführen/loggen usw. ohne das ein Monatelanges Projekt daraus wird. Eben Anwendungen wo weder der Code noch die Geschwindigkeit/Effizienz vorderrangig ist sondern das damit erreichte Ergebnis, eben zB. in Forschungsprojekten wo man keine Wochen für eine im Endeffekt sowieso nebensächliche Messung verschwenden möchte.
A. K. schrieb: > Python ist sehr geeignet für die ganze "Zwischendurch-SW" also zB. Daten > von Messgeräten/IO-Karten/Netzwerk einlesen und damit Berechnungen > durchführen/loggen usw. ohne das ein Monatelanges Projekt daraus wird. Geht mit z.B. Tcl genauso. Incl. LXI-Server und die Daten für GnuPlot aufbereiten und damit darstellen..
Nick M. schrieb: > Geht mit z.B. Tcl genauso. Incl. LXI-Server und die Daten für GnuPlot > aufbereiten und damit darstellen.. Und nicht nur damit sondern mit mindestens nem Dutzend anderer Skriptsprachen. Aber scheinbar hat Python etwas was die Leute wollen, Tcl nicht. Und nu?
Sheeva P. schrieb: > Einerseits sehe ich das (noch?) lange nicht, daß Rust eine größere Rolle > spielt, im Moment scheint das Momentum eher bei Go zu liegen. Naja, kommt darauf an, in welchem Gebiet man sich bewegt. Go kann C und C*+ nicht ersetzen, da es keine Sprache ist, die für die Systemprogrammierung geeignet ist. Rust schon. Rust ist vom Einsatzfeld viel näher an C und C++ als es Go je war, kann aber trotzdem auch in Gebiete vorrücken, für die man C oder C++ nur ungern verwenden würde. > Andererseits spielt Rust in einer Diskussion, in der es um die > (meistens) interpretierte General-Purpose-Skriptsprache Python geht, > wohl auch keine Rolle. Ja, das ist natürlich wahr. Ich wollte es nur mal erwähnen, weil du von (r)evolution sprachst.
Le X. schrieb: > Aber scheinbar hat Python etwas was die Leute wollen, Tcl nicht. > Und nu? Vivado, Quartus ohne Tcl? Und nu? Es läuft immer nur auf einen Sprachen-Krieg raus. Genauso wie Atmel PIC oder Arm.
Den professionellen, kommerziellen Bereich mag ich jetzt nicht beurteilen. Aber ich denke im privaten Hobbybereich und auch in Schule/Ausbildung hat der Raspberry maßgeblich zur Popularität von Python beigetragen weil die Raspberry-Entwickler/Foundation diese Sprache favorisieren und es einfach massiv viele Tutorials und Hilfen dazu für den Raspberry gibt. Will man irgendwas mit Raspberry automatisieren, findet man höchstwahrscheinlich Hilfestellungen mit Python dazu, obwohl das Problem auch mit einer anderen Sprache lösbar wäre. Und durch diese so entstandene Popularität von Python, wird diese Sprache auch immer mehr auf Windows-Systemen eingesetzt.
Ben S. schrieb: > Sheeva P. schrieb: >> Die Lesbarkeit von Code hängt allerdings nicht nur von der Formatierung >> ab. > > Doch, fast immer. Und Du redest von Noobs, sogar von Softwareentwicklung? Das kann ich gar nicht glauben. Ein gestandener Softwareentwickler hätte meine -- mit großem Bedacht eingefügte -- Formulierung "nicht NUR" gelesen und verstanden. > Sheeva P. schrieb: >> Das ist, wie so vieles, reine Übungssache. Jedenfalls erzwingt diese >> Eigenschaft eine saubere Blockeinrückung, und mir ist unverständlich, >> wie das die Lesbarkeit verschlechtern sollte, das ist ja völlig abstrus. > > Ach, jetzt soll ich eine furchtbare Formatierungseigenschaft üben, bis > ich diese kann? Pardon, aber was Du machst oder nicht, ist mir ziemlich gleichgültig. Ich habe nur von meinen Erfahrungen mit Python geredet, also denen, die Du offensichtlich nicht hast und auch nicht haben willst. Von mir aus, na und? Warum gehst Du hier bloß so hoch, wenn jemand von seinen positiven Erfahrungen mit einer Sprache erzählt, die Du offensichtlich nicht leiden kannst? Geh' mal 'ne Runde an die frische Luft, das ist gut für die Gesundheit und das Gemüt. > Ich sehe keinen praktischen Grund auf einem mikrocontroller python > einzusetzen., bitte nenne mir einen. Weil man's kann. Weil die Software womöglich sehr häufig angepaßt und verändert werden muß und Entwicklungszeit darum eine große Rolle spielt. Weil andere Leute womöglich keine Profientwickler sind und trotzdem Zugang zu Elektronikspielzeug bekommen sollen -- da haben die Arduino-Jungs sogar ein ziemlich großes Projekt draus gemacht. Abgesehen davon war die Frage des TO nicht auf Mikrocontroller, sondern nur auf die Gründe für den Erfolg von Python gerichtet. Daß man es auch auf Mikrocontrollern nutzen kann, war lediglich eine Randbemerkung. Aber spannend, daß die Armada der Mikrocon-Trolle jetzt darauf anspringt wie ein Hund auf seinen Knochen.
Markus M. schrieb: > [...] oder findet jemand das übersichtlich? > >
1 | > aws ec2 describe-instances | python3 -c 'import json; import sys; import |
2 | > re; d = json.load(sys.stdin); [[[print(i["InstanceId"]) for t in |
3 | > i["Tags"] if t["Key"] == "Name" and re.search("mein_regex", t["Value"],
|
4 | > flags=re.I) ] for i in x["Instances"]] for x in d["Reservations"]]' |
5 | > |
Nein, natürlich nicht. Aber versuch' das mal in C, C++, oder Java... ;-) > Was die fehlende Typisierung angeht gibt es Abhilfe: > > https://docs.python.org/3/library/typing.html Sie fehlt ja nicht, sie ist nur an den Value gebunden statt ans Symbol. Das ist nicht wie in PHP oder Perl, wo 12 / '4' tatsächlich 3 ergibt -- Python und Ruby werfen dort korrekterweise eine Exception. Die Type Hints in Python sind super, werden aber vom Interpreter nicht durchgesetzt; das muß man vorher mit einem externen Tool prüfen.
Walter T. schrieb: > Python ist perfekt für die kleine Skript-Aufgabe zwischendurch. Für > große Rechenaufgaben nimmt man effiziente Programmiersprachen wie Matlab > und Fortran. Da ist es aber wirklich komisch, daß Python gerade dort besonders beliebt ist, wo es um die größten Datenmengen geht: Big Data, Data Science, Machine und Deep Learning... übrigens: Python-Frameworks wie numpy, scipy und Pandas benutzen intern oft genau dieselben Numbercrunching-Bibliotheken wie Matlab & Co... ;-)
Roland F. schrieb: > Ich fand schon immer die Entscheidung, das die Quelltextformatierung > Teil der Syntax b.z.w. Semantik ist schlecht. Bei (altem) Fortran oder > make mag das ja noch historisch begründbar sein, aber modernen Sprachen > wie Python (Entstehungsjahr 1991) sollte das eigentlich keine > Spracheigenschaft mehr sein. Das war eine bewußte Entscheidung, um die Lesbarkeit zu erhöhen und die Entwickler zu zwingen, sauberen Code zu schreiben. Und das funktioniert tatsächlich ziemlich gut.
Sheeva P. schrieb: > Das war eine bewußte Entscheidung, um die Lesbarkeit zu erhöhen und die > Entwickler zu zwingen, sauberen Code zu schreiben. Und das funktioniert > tatsächlich ziemlich gut. Das könnte man vielleicht auch bei C/C++ optional einführen. Funktionsblöcke ohne Einrückungen können da ja schon mal zu schweren Übersichtsproblemen führen. Am besten eine Option "automatisierte Einrückung" auf Mausklick im markierten Bereich :)
Wodjanoi schrieb: > Und das ist eine ernsthafte Anwort - ein Compiler würfelt nicht. Der > Source definiert immer einen eindeutigen Compileroutput. Natürlich > können zwei verschiedene Compiler (anderer Hersteller, Revisionen) > unterschiedliche Outputs erzeugen. Vielleicht ein plus von Python das > weniger Interpreter-Hersteller und -varianten kennt als C in seiner fast > 48-jährigen Geschichte. Für Python fallen mir als Interpreter schon vier ein -- die Referenzimplementierung CPython, der performanceoptimierte Pypy, das in Java geschriebene Jython und das in C# geschriebene IronPython. Hinzu kommen mindestens zwei Compiler, nuitka und einer, dessen Name mir gerade entfallen ist.
Ich gehe jetzt nicht auf alles ein, was seit meinem letzten Post geschrieben wurde. Aber auch mich überzeugt das Konzept "Strukturierung mit Whitespace" nicht. Das erwarte ich eher in einer Joke-Sprache wie eben "Whitespace" zu finden, als in einer ernstgemeinten Programmiersprache. Der Vergleich mit C (oder anderen Sprachen, die Klammern verwenden) hinkt dahingehend, daß man alle diese Sprachen automatisch einrücken lassen kann. Was gerade beim Refaktoring oder kopieren von Code zwischen Projekten enorm praktisch ist. Vergessene Klammern kann man dadurch auch leicht finden, weil man nach der Re-Indentierung die Code-Struktur so sieht, wie der Compiler. Bei Python hat man diese Möglichkeit nicht. Entweder die Indentierung (und damit Struktur) stimmt oder sie stimmt nicht. Der Hauptgrund, warum ich Python bis jetzt nicht angefaßt habe, ist aber ein anderer: es gibt schlicht keine Lücke, die Python bei mir füllen könnte. Was andere hier anscheinend gerne mit Python machen, mache ich mit Perl. Geschwindigkeit war nie ein Thema und instabile Perl-Programme habe ich auch noch nie gehabt. Ja, Perl ist extrem ausdrucksstark, fast wie eine natürliche Sprache (da kommt natürlich Larrys Background als Linguist durch). Man kann dadurch in Perl extrem gut lesbaren Code schreiben. Andererseits kann man auch extremes Kauderwelsch produzieren. Aber das kann man bekanntlich in jeder Programmiersprache. Persönlich mag ich Freiheit lieber als Zwang. Auch wenn es der Zwang zu einem besonderen Programmierstil ist, den jemand (oder meinetwegen auch die Allgemeinheit) als besonders lesbar ansieht.
Heiner schrieb: > Das ist Teil eines größeren Plans, Konstrukte möglichst nahe an der > natürlichen Sprache zu halten. In C und ähnlichen Sprachen würde es > ungefähr heißen: > for (int i = 0; i < max; i++) { ... > ... und dann benutzt man i z.B. für den Zugriff auf ein Array. Was die > drei Blöcke in der Klammer bedeuten, muss man selbst wissen. Die Syntax > gibt darauf keinerlei Hinweise. Das ist eben die Sichtweise von C. Und ich kann solche Zusammenziehungen üerhaupt NICHT leiden: for (int i = 0; ... anständigerweise würde man es so schreiben: int i; ... for (i = 0; ... Bei Pascal wäre das weitaus lesbarer: var i : integer; ... for i:= 0 to 4711 do irgendwas; oder for i:= 4711 downto 0 do irgendwas; Du wirst wohl nicht bestreiten, daß das ausgesprochen klar lesbar ist. > Python macht daraus ein einfaches: > for abc in xyz: Das wiederum ist extrem unverständlich und auch genau so nicht erwünscht. Der Grund ist, daß man in einer for-Anweisung ja auch die Möglichkeit haben will, dediziert auf das vorherige oder nächste Element zugreifen zu können. Und ohne eine dedizierte Laufvariable geht das nicht. Und die Unverständlichkeit rührt aus der Mengenalgebra her: if element in menge then tuwasdamit; konkret: if (Ch in ['0'..'9','.','-','+']) then ... aber genau DAS scheint mir bei Python eben nicht gemeint zu sein. > ... wobei in den meisten Fällen die Iterationsvariable ganz wegfällt, > weil xyz selbst eine iterierbare Klasse ist und "selbst weiß, wie man > sich aufzählt" Nö. Eine Objektklasse kann sich nicht selbst aufzählen. Dazu würden nämlich die konkret instantiierten Members erforderlich sein, denn die wären es ja, die da aufgezählt werden sollen. Die Klasse an sich weiß das nicht, sie ist ja nur der Datentyp, aber nicht die Instantiierung durch konkrete Variablen. W.S.
Hans schrieb: > W.S. schrieb: >> Aber hier bei Python haben wir stattdessen >> unterschiedliche Anzahl von 'white space' Zeichen! >> >> Und was passiert dort, wenn man 1x Space und dann 1x Tab schreibt? >> Nein, nicht mit mir. > > Das ist ja wirklich übel. Ich stelle mir da die Fehlersuche sehr > kompliziert vor. Mir war nicht klar, dass es noch moderne > Programmiersprachen mit nennenswerter Verbreitung dieser Art gibt. Das ist gar nicht übel. Der Interpreter erkennt das, während er den Quellcode in Bytecode übersetzt, und bricht mit einer eindeutigen Fehlermeldung ab. WS hat mal wieder keine Ahnung, was er faselt.
DoS schrieb: > Mega grottig ist die "GUI-Fähigkeit" die ist auf dem Niveau von 1988. Du meinst die Anbindungen an Qt, WxWidgets, GTK, und die GUI-Toolkits von Java und C#? > Wenn ich das mit VisualBasic aus den 1990ern vergleiche, war das damals > besser gelöst. Nur: damals gab es halbwegs genormte Monitore. Heute muss > eine GUI dynamisch skalieren. Da kann es nicht sein, dass Buttons und > andere Grafikelemente per Pixel positioniert und definiert werden und > das Look and Feel des Betriebssystem nicht wiederspiegelt. Das Ausrichten kann sogar das in Python standardmäßig enthaltene Tk...
:
Bearbeitet durch User
Rolf M. schrieb: > Das wird immer wieder als das große "Problem" aufgetan. Irgendwie > verstehe ich das nicht. Es erzwingt halt vernünftige Einrückung. Es IST ein großes Problem, oder besser gesagt eine große Sauerei. Man macht sowas nicht in einer Programmiersprache. OK, wir nehmen Fortran hier mal heraus, das hat Alters-Bestandsschutz. Aber für alle anderen sogenannten 'probllemorientierten' Programmiersprachen (im Klartext: alles außer Assembler) gilt, daß man für Blöcke eben Kennzeichner hat. Python hat diese nicht und Einrückungen sind keine derartigen Kennzeichner, sondern nur ein Mittel zur grafisch angenehmen Darstellung. Darum. W.S.
Nick M. schrieb: > A. K. schrieb: >> Python ist sehr geeignet für die ganze "Zwischendurch-SW" also zB. Daten >> von Messgeräten/IO-Karten/Netzwerk einlesen und damit Berechnungen >> durchführen/loggen usw. ohne das ein Monatelanges Projekt daraus wird. > > Geht mit z.B. Tcl genauso. Incl. LXI-Server und die Daten für GnuPlot > aufbereiten und damit darstellen.. Dann zeig' mir doch bitte mal etwas in Tcl, das auch nur ansatzweise mit numpy, Scipy, Pandas, Bokeh, Seaborn, ggplot oder geoplotlib mithalten kann. Danke. Auf die Gefahr hin, mich zu wiederholen: es gibt gute Gründe dafür, daß Python vor allem dort besonders beliebt ist, wo Leute professionell mit riesigen Datenmengen umgehen (müssen), etwa Data Science, Big Data und Machine Learning... Das paßt (für die, die es noch nicht mitbekommen haben) natürlich auch nicht zu der hier häufiger vorgetragenen Behauptung, Python sei langsam oder nicht für große Projekte geeignet.
//.|.\\ schrieb: > Und woher weiss der Compiler, wo die Klammer hinsoll ??? Junge, eben weil am Ende eine öffnende oder schließende zuviel ist. Spätestens dann merkt er es. Da können dann zwar einige Zeilen dazwischen liegen, aber man wir wenigstens drauf aufmerksam gemacht. Das ist der Punkt. W.S.
Das angebliche Python-Whitespace/Tab-Problem ist eine Schein-Diskussion,
das Problem existiert nicht:
a.) Weiter oben wurde schon geschrieben, Python (3) bringt eine
Fehlermeldung bei mixed Whitespace/Tabs.
b.) Jeder f*cking Editor kann eingestellt werden, wie die Tab-Taste
funktionieren soll, ob Whitespace oder Tab, etc.
c.) editorconfig ist erfunden. Jedes Projekt kann seine eigenes Setting
verwenden, und man merkt nicht mal was davon, egal welchen Editor
man verwendet.
Wozu sich über etwas Gedanken machen, das längst komplett gelöst ist?
Macht sich hier einer Gedanken, auf welchen Sektor einer Festplatte eine
Datei gespeichert wird?
Wer natürlich heute noch (ungewartete) Editoren aus dem letzten
Jahrtausend benutzt, nun denn, werdet glücklich damit und plagt euch mit
Nebensächlichkeiten rum.
W.S. schrieb: > Rolf M. schrieb: >> Das wird immer wieder als das große "Problem" >> aufgetan. Irgendwie verstehe ich das nicht. Es >> erzwingt halt vernünftige Einrückung. > > Es IST ein großes Problem, oder besser gesagt eine > große Sauerei. Naja, vor allem finde ich Rolfs Verteidigung arg willkürlich. Wenn ich C kritisiere, dann ist jeder Zwang des Teufels, und Freiheit das oberste Gebot. Wenn man Python kritisiert, ist plötzlich der Zwang zu vernünftiger Einrückung richtig?! Also, echt jetzt...
Bastler schrieb: > Den professionellen, kommerziellen Bereich mag ich jetzt nicht > beurteilen. Aber ich denke im privaten Hobbybereich und auch in > Schule/Ausbildung hat der Raspberry maßgeblich zur Popularität von > Python beigetragen Es sind zwar bislang weltweit etwa 30 Millionen RasPis verkauft worden, trotzdem ist das ein ziemliches Nischenprodukt für... spezielle Leute. Und der Siegeszug von Python ist schon viel älter als die RasPis... ;-)
Irgendwer schrieb: > Das angebliche Python-Whitespace/Tab-Problem ist > eine Schein-Diskussion, Keineswegs. > das Problem existiert nicht: Doch. Dass die Blockstruktur in Python durch Einrückung definiert wird, bedeutet im Umkehrschluss, dass es kein druckbares Zeichen (wie z.B. "begin", "end", "{","}",...) gibt, das die Blockstruktur definiert. Das ist schlecht, denn die gesprochene Sprache kennt die Sprachmelodie als Kanal für die Meta-Daten, die geschriebene natürliche Sprache kennt die Interpunktion, und die allermeisten Programmiersprachen kennen Schlüsselworte oder Sonderzeichen dafür. Nur Python kennt nix.
Axel S. schrieb: > Ich gehe jetzt nicht auf alles ein, was seit meinem letzten Post > geschrieben wurde. Aber auch mich überzeugt das Konzept "Strukturierung > mit Whitespace" nicht. > [...] > Der Hauptgrund, warum ich Python bis jetzt nicht angefaßt habe, Es ist schon seltsam, daß sich hier vor allem jene über die Whitespace-Geschichte echauffieren, die nur wenig bis gar keine Python-Erfahrung haben. > Ja, Perl ist extrem ausdrucksstark, fast wie eine natürliche Sprache (da > kommt natürlich Larrys Background als Linguist durch). Man *kann* > dadurch in Perl extrem gut lesbaren Code schreiben. Das gilt in noch höherem Maße für Python, und... sorry, aber einer meiner Gründe, nach über dreizehn Jahren von meiner damaligen Standard-Skriptsprache Perl zu Python zu wechseln, waren auch Pythons bessere Lesbarkeit, Ausdrucksstärke, und Performanz.
Sheeva P. schrieb: > Es ist schon seltsam, daß sich hier vor allem jene > über die Whitespace-Geschichte echauffieren, die nur > wenig bis gar keine Python-Erfahrung haben. Nein -- das ist logisch: Eine Sprache, die solchen Blödsinn als unverrückbares Element enthält, die fasse ich nicht an, egal, wie gut sie ansonsten ist. Überdies habe ich ja auch keinen Bedarf; ich bin mit Tcl zufrieden. Ich würde auch kein Kabel kaufen, das eine rote Ader für den Schutzleiter enthält, "nur um den Elektriker zu erhöhter Aufmerksamkeit zu zwingen".
W.S. schrieb: > Rolf M. schrieb: >> Das wird immer wieder als das große "Problem" aufgetan. Irgendwie >> verstehe ich das nicht. Es erzwingt halt vernünftige Einrückung. > > Es IST ein großes Problem, oder besser gesagt eine große Sauerei. Man > macht sowas nicht in einer Programmiersprache. Doch, macht man. Python macht das so und hat sich auch deswegen zur mit Abstand beliebtesten und verbreitetsten Skriptsprache entwickelt. Wie blöd, daß der Rest dieser schönen Welt auf Deine Ansichten pfeift...
Egon D. schrieb: > Das ist schlecht, denn die gesprochene Sprache kennt > die Sprachmelodie als Kanal für die Meta-Daten, die > geschriebene natürliche Sprache kennt die Interpunktion, > und die allermeisten Programmiersprachen kennen > Schlüsselworte oder Sonderzeichen dafür. Nur Python > kennt nix. Aber ja doch. Einrückungen. Meine Güte, ist das wirklich so schwer?
Egon D. schrieb: > Nur Python kennt nix. Tja. Wenn Du wüsstest, das es noch eine ganze Reihe aktueller, aktueller Programmiersprachen gibt, bei denen Struktur durch Einrückung erzeugt wird... Sheeva P. schrieb: > Es ist schon seltsam, daß sich hier vor allem jene über die > Whitespace-Geschichte echauffieren, die nur wenig bis gar keine > Python-Erfahrung haben. Ich würde noch weiter gehen und behaupten, die meisten Kritiker (hier) haben noch nie ernsthaft programmiert und kennen maximale vielleicht eine oder zwei Programmiersprachen.
Beitrag #6490545 wurde von einem Moderator gelöscht.
Irgendwer schrieb: > Sheeva P. schrieb: >> Es ist schon seltsam, daß sich hier vor allem jene über die >> Whitespace-Geschichte echauffieren, die nur wenig bis gar keine >> Python-Erfahrung haben. > > Ich würde noch weiter gehen und behaupten, die meisten Kritiker (hier) > haben noch nie ernsthaft programmiert und kennen maximale vielleicht > eine oder zwei Programmiersprachen. Das deckt sich mit meinen Vermutungen. ;-)
W.S. schrieb: > Python hat diese nicht und Einrückungen sind keine derartigen > Kennzeichner, sondern nur ein Mittel zur grafisch angenehmen > Darstellung. Quelltext wird einmal geschrieben, und ein vielfaches oft gelesen. Einem Compiler ist es egal, nach welchen Regeln hierarchische Strukturen kodiert werden. Ob Klammern, Schlüsselwörter oder Einrücktiefe. Piep egal, für einen Compiler. Aber einem Menschen ist es nicht egal. In der Wahrnehmungspsychologie ist es von oben bis unten durchgeforscht: Dein Hirn nimmt eingerückte Strukturen deutlich schneller und einfacher wahr als verschachtelte Klammern. Unsere ganze Schriftkultur besteht aus Blöcken und Einrückungen. In allen (strukturierten) Programmiersprachen dieser Welt, rücken Programmierer ihren Quelltext hierarchisch ein, weil es sonst keine Sau mehr lesen kann. Es ist nur logisch, die Einrückung zur Strukturierung zu verwenden. Dann ist es nicht möglich, eine Diskrepanz aus Einrückung und tatsächlicher Struktur des Quelltexts zu erzeugen. Eine Fehlerquelle weniger, mehr Klarheit und Konsistenz, bessere Lesbarkeit. Und genau das ist ein entscheidende Faktor für Software-Qualität: Klar verständlicher Quelltext. Quelltext wird für Menschen geschrieben, die den Kram lesen und verstehen müssen.
Beitrag #6490554 wurde von einem Moderator gelöscht.
Irgendwer schrieb: > Aber einem Menschen ist es nicht egal. In der > Wahrnehmungspsychologie ist es von oben bis unten > durchgeforscht: Dein Hirn nimmt eingerückte > Strukturen deutlich schneller und einfacher wahr > als verschachtelte Klammern. Stopp. Du verdrehst den Sinn der gemachten Aussagen. Niemand hat gefordert, dass man nicht einrücken solle. Die Aussage war nur: Der VERZICHT auf "Interpunktion" (d.h. druckbare Zeichen für die Blockstruktur) ist schlecht. > Unsere ganze Schriftkultur besteht aus Blöcken und > Einrückungen. ... und aus Interpunktion. > In allen (strukturierten) Programmiersprachen dieser > Welt, rücken Programmierer ihren Quelltext hierarchisch > ein, weil es sonst keine Sau mehr lesen kann. Korrekt. > Es ist nur logisch, die Einrückung zur Strukturierung > zu verwenden. Nein -- umgekehrt: Es wäre logisch, wenn der Computer die Einrückung automatisch aus der Klammerung erzeugen würde (oder -- alternativ -- die Klammer selbst setzt, wenn ich einrücke). Der Mensch braucht die Einrückung, das ist korrekt -- ich will aber dem Computer nicht durch die Anzahl der Leerzeichen mitteilen müssen, welche Blockstruktur ich haben will! Setzer können schon seit Jahrhunderten verschieden breite Leerräume erzeugen -- trotzdem setzen wir noch einen Punkt, wenn der Satz zu Ende ist. Auch der Morsecode beschränkt sich nicht auf "Ton" und "Pause", obwohl das theoretisch ausreichend wäre, sondern verwendet "kurzer Ton", "langer Ton" und "Pause".
Egon D. schrieb: > Du verdrehst den Sinn der gemachten Aussagen. Niemand > hat gefordert, dass man nicht einrücken solle. Die > Aussage war nur: Der VERZICHT auf "Interpunktion" (d.h. > druckbare Zeichen für die Blockstruktur) ist schlecht. Python hat doch Interpunktion, mindestens den Doppelpunkt am Ende einer Zeile, die einen neuen Block einleitet:
1 | if 1 < 2: |
2 | print('yes')
|
Egon D. schrieb: > Nein -- umgekehrt: Es wäre logisch, wenn der Computer die > Einrückung automatisch aus der Klammerung erzeugen würde > (oder -- alternativ -- die Klammer selbst setzt, wenn ich > einrücke). Dafür gibt es ja inzwischen für die meisten Programmiersprachen automatische Code-Formatierer wie prettier, clang-format etc. Seitdem ich diese für alles Mögliche einsetze, habe ich viel mehr Zeit, mir inhaltlich um den Code, den ich schreibe, Gedanken zu machen: einmal Speichern mit Ctrl-S und der Code ist hübsch. Egon D. schrieb: > Auch der Morsecode beschränkt sich nicht auf "Ton" und > "Pause", obwohl das theoretisch ausreichend wäre, sondern > verwendet "kurzer Ton", "langer Ton" und "Pause". Dann aber bei dem Beispiel bitte nicht vergessen, dass es neben den beiden Tonlängen (kurz/lang) auch drei verschiedene Pausenlängen braucht (zwischen Tönen, zwischen Buchstaben und zwischen Wörtern).
Beitrag #6490576 wurde von einem Moderator gelöscht.
Max M. schrieb: > Python hat doch Interpunktion, mindestens den Doppelpunkt am Ende einer > Zeile, die einen neuen Block einleitet: In Verbindung mit einem anständigen Editor gibt es sogar in Python ein Schlüsselwort, das man zur Beendigung eines Blocks und automatischen Ausrückung mißbrauchen kann: pass. Das macht den Code zwar häßlich und schlechter lesbar, ist in bestimmten Fällen allerdings durchaus hilfreich...
Max M. schrieb: > Egon D. schrieb: >> Du verdrehst den Sinn der gemachten Aussagen. Niemand >> hat gefordert, dass man nicht einrücken solle. Die >> Aussage war nur: Der VERZICHT auf "Interpunktion" (d.h. >> druckbare Zeichen für die Blockstruktur) ist schlecht. > > Python hat doch Interpunktion, mindestens den Doppelpunkt > am Ende einer Zeile, die einen neuen Block einleitet: > if 1 < 2: > print('yes') Ach. Na jetzt bin ich ja baff. Habe ich das jetzt richtig verstanden: Außer Dir hält es NIEMAND -- nicht einmal die deutschsprachige Wikipädie -- für wichtig, auf den verbreiteten Irrtum hinzuweisen, das in Python die Blockstruktur gar nicht AUSSCHLIESSLICH durch Einrückungen definiert wird, sondern durch DOPPELPUNKTE IN KOMBINATION MIT EINRÜCKUNG? Ist das korrekt bei mir angekommen? > Egon D. schrieb: >> Nein -- umgekehrt: Es wäre logisch, wenn der Computer >> die Einrückung automatisch aus der Klammerung erzeugen >> würde (oder -- alternativ -- die Klammer selbst setzt, >> wenn ich einrücke). > > Dafür gibt es ja inzwischen für die meisten Programmier- > sprachen automatische Code-Formatierer wie prettier, > clang-format etc. Ja, ist im Prinzip klar. Es ging mir um einen anderen Punkt: Mein Vorschreiber "Irgendwer" hat zu Recht daraufhingewiesen, dass 1. der Mensch für seine Wahrnehmung Einrückungen braucht und 2. Redundanz gefährlich sein kann, weil redundante Angaben widersprüchlich sein können. Er hat daraus -- m.E. zu Unrecht -- gefolgert, es dürfe nur genau EINE Methode geben, die Blockstruktur deutlich zu machen, und das müsse eben die Einrückung sein. Mein Gegenargument ist: Die Mensch-Maschine-Kommunikation hat zwei Richtungen, nämlich Mensch-->Maschine und Maschine-->Mensch. Für die Richtung "Mensch-->Maschine" möchte ich DRUCKBARE Zeichen, die die Blockstruktur DEFINIEREN. Um Widersprüche durch schädliche Redundanz zu vermeiden, folgt daraus, dass die für die Richtung "Maschine-->Mensch" notwendigen Einrückungen AUTOMATISCH aus den druckbaren Zeichen generiert werden müssen. Diese SIGNALISIEREN die Blockstruktur NUR FÜR DEN MENSCHEN, sind aber für die Maschine nicht verbindlich, sondern im Gegenteil abgeleitete (=redundante) Informationen. > Egon D. schrieb: >> Auch der Morsecode beschränkt sich nicht auf "Ton" und >> "Pause", obwohl das theoretisch ausreichend wäre, sondern >> verwendet "kurzer Ton", "langer Ton" und "Pause". > > Dann aber bei dem Beispiel bitte nicht vergessen, dass > es neben den beiden Tonlängen (kurz/lang) auch drei > verschiedene Pausenlängen braucht (zwischen Tönen, > zwischen Buchstaben und zwischen Wörtern). Theoretisch sicherlich richtig. Praktisch ist die Bedeutung dessen fraglich, wenn chiffrierte Fünfergruppen gesendet werden :)
Beitrag #6490590 wurde von einem Moderator gelöscht.
Diese ganze Whitespace-Diskussion liest sich irgendwie, als würde der Stumme dem Blinden Farben erklären. Kann gutgehen, ist aber meist ne Sauerei. Kann nicht mal einer ein Beispiel geben, damit alle wissen worüber Diskutiert wird? Die Behauptung ist doch, dass Pseudocode A:
1 | res = 0 |
2 | for i in 1..2: |
3 | res = res+1 |
4 | res = res+1 |
Pseudocode B:
1 | res = 0 |
2 | for i in 1..2: |
3 | res = res+1 |
4 | res = res+1 |
in python kein Fehler ist, aber komplett andere Ergebnisse (Fall A: 4, Fall B: 3) liefert - in den "klammerbasierten" Sprachen aber ein Fehler wäre, weil dann irgendwo eine Klammer vergessen wurde. Meine Meinung: a) Whitespace ist nicht optimal, es macht Code kopieren und neu strukturieren zur Strafarbeit. b) Äpfel mit Birnen verglichen, der äquivalente Fehler in "klammerbasierten" Sprachen ist nicht "Klammer vergessen" sondern "Statement außerhalb des Blocks" Wobei man bei a) noch einwerfen kann, das das Absicht ist: Code einfach aus dem Netz kopieren und hoffen ist idiotisch. Die Realität: Ich schreibe code in sh und bash. Mit perl bin ich nie warm geworden, komme mit gut strukturiertem Fremdcode aber klar. Bei Python bin ich über einige Schnipsel und das flicken von Fremdquellen nie hinaus gekommen - nicht das ich nicht wollte, aber entweder es gab kein Python (Router, embedded), ich hatte keine Zeit das zu lernen oder der Editor bereitete Schmerzen. Versuche, python zu lernen mach ich immer wieder.
M.K. B. schrieb: > Als Nachteil für größere Projekte empfinde ich die fehlende Typisierung. > Viele Fehler in Python würde in C/C++ der Compiler als Typfehler melden > und es nicht beim Aufruf eine Fehlermeldung geben. Das kannst du auch in Python bekommen. Type hints sind Bestandteil der Sprache, und mit mypy gibt es ein statisches Analysetool das diese auf Konsistenz prüft. Ich habe damit in größeren Projekten sehr gute Erfahrungen gemacht. Die Whitespacediskussion halte ich für völlig überzogen. Ich habe bis vor ein paar Jahren auch nur mit anderen Sprachen gearbeitet die so etwas nicht hatten, aber da gewöhnt man sich schnell dran, lernt es sogar zu schätzen (und man spart sich im Code Review die Diskussion darüber ob etwas richtig eingerückt ist).
W.S. schrieb: > Rolf M. schrieb: >> Das wird immer wieder als das große "Problem" aufgetan. Irgendwie >> verstehe ich das nicht. Es erzwingt halt vernünftige Einrückung. > > Es IST ein großes Problem, Für mich ist es das nicht. Du konntest bisher auch leider nicht darlegen, warum das ein Problem sein soll, außer weil du dann eben nicht mehr kreuz und quer einrücken darfst. > oder besser gesagt eine große Sauerei. Man macht sowas nicht in einer > Programmiersprache. Bei dir und vielen anderen hier im Thread fällt mir auf, dass ihr sagt: "Ich kann das nicht leiden", "das kommt mir nicht ins Haus", "das macht man nicht", "das ist ja ganz furchtbar", aber ohne jegliche Begründung. Nur sehr wenige nennen überhaupt konkrete Gründe, die auch durchaus plausibel, aber für mich nicht unbedingt ein k.o.-Kriterum sind. Egon D. schrieb: > Naja, vor allem finde ich Rolfs Verteidigung arg > willkürlich. > > Wenn ich C kritisiere, dann ist jeder Zwang des Teufels, > und Freiheit das oberste Gebot. > Wenn man Python kritisiert, ist plötzlich der Zwang > zu vernünftiger Einrückung richtig?! Wo hab ich denn sowas behaupet? In C gibt es auch Zwänge, wie in jeder Programmiersprache. Und auch in C rücke ich trotz fehlenem Zwang ordentlich ein. Egon D. schrieb: > und die allermeisten Programmiersprachen kennen > Schlüsselworte oder Sonderzeichen dafür. Nur Python > kennt nix. Das Leerzeichen ist in der Hinsicht wie die 0 in der Mathematik. Die ist auch nicht "nix", denn eine 0 mehr oder weniger am Ende des Kontostandes macht einen riesen Unterschied. Egon D. schrieb: > Er hat daraus -- m.E. zu Unrecht -- gefolgert, es dürfe > nur genau EINE Methode geben, die Blockstruktur deutlich > zu machen, und das müsse eben die Einrückung sein. Dass das sein müsse, hat er nicht gesagt, nur dass es die logische Konsequenz wäre. Und die ist es ja auch. Als Mensch bin ich auf die Einrückung angewiesen. Für den Interpreter kann ich mir aussuchen, was er nimmt. Da wäre doch tatsächlich die logische Konsequenz, die dort auch einzusetzen, statt für den nochmal ein zusätzliches redundantes Element einzuführen, das eben zu dem Risiko von Inkonsistenzen zwischen den beiden führen kann. Ben S. schrieb: > Ach, jetzt soll ich eine furchtbare Formatierungseigenschaft üben, bis > ich diese kann? Saubere Einrückung ist für dich eine "furchtbare Formatierungseigenschaft"? Eigentlich sollte sie eine Selbstverständlichkeit sein. Klaus H. schrieb: > Bei C/C++ eine Klammer falsch gesetzt? Pech gehabt, stundenlange > Fehlersuche. Ja, vor allem, wenn es richtig eingerückt ist und eben nur die Klammer falsch ist. Ich schaue mir die Einrückung an und denke: "passt", und den Compiler interessiert die aber gar nicht, und er macht was ganz anderes draus. Solche Fälle hatte ich in C bei Fremdcode schon, in Python könnte das gar nicht passieren. Wodjanoi schrieb: > Und das ist eine ernsthafte Anwort - ein Compiler würfelt nicht. Der > Source definiert immer einen eindeutigen Compileroutput. Bei undefiniertem Verhalten nicht. Das ist - wie der Name schon sagt - gar nichts definiert. Und das bedeutet auch, dass der Compiler durchaus auch würfeln dürfte. Die meisten tun das allerdings nicht, aber an vielen Stellen kümmern sie sich einfach nicht darum, was dort dann passiert. Klaus schrieb: > Ich habe gültigen Code geschrieben. Der Sprachstandard und der Compiler > haben daraus undefiniertes Verhalten gemacht. Das ist aber eine merkwürdige Ansicht. Du hast Code geschrieben, der gegen den Standard verstößt, und nun erklärst du ihn zu gültigem Code und beanstandest, dass der Standard ihn ungültig mache. Das klingt fast, wie wenn sich jemand nach eine Wahlniederlage einfach selbst zum Gewinner erklärt. Nick M. schrieb: > Vor allem, wenn man zur Fehlersuche ein Stück code oder einen Test > einfügt und man dazu neu formatieren muss. Und danach den test-code > löschen und wieder neu formatieren. Brilliant! > Ich pflege meinen Testcode linksbündig zu schreiben, weil ich den > schneller finde und er sowieso den Tag nicht überleben wird. Ja, das ist eine Sache, die mich tatsächlich auch stört, weil ich das von C++ auch gewöhnt bin, das so zu tun. Wobei es etwas Gewöhnungssache ist. Bevor ich den Code einchecke, diffe ich ihn sowieso nochmal gegen die ursprügnliche Version. Da sieht man den eingefügten Code auch sofort und kann ihn dann noch entfernen. LOL schrieb: > Die Behauptung ist doch, dass > Pseudocode A: > res = 0 > for i in 1..2: > res = res+1 > res = res+1 > > Pseudocode B:res = 0 > for i in 1..2: > res = res+1 > res = res+1 > > in python kein Fehler ist, aber komplett andere Ergebnisse (Fall A: 4, > Fall B: 3) liefert - in den "klammerbasierten" Sprachen aber ein Fehler > wäre, weil dann irgendwo eine Klammer vergessen wurde. Die gleichen Schleifen wären in C so auch kein Fehler, aber hätten das selbe Ergebnis, obwohl man beim Überfliegen des Code auf Grund der Einrückung etwas unterschiedliches erwarten könnte. W.S. schrieb: > Das ist eben die Sichtweise von C. Und ich kann solche Zusammenziehungen > üerhaupt NICHT leiden: > for (int i = 0; ... > > anständigerweise würde man es so schreiben: > int i; > ... > for (i = 0; ... Das ist überhaupt nicht anständig. i ist der Schleifenzähler. Er ist nur für die Schleife da und sollte deshalb logischerweise auch nur in der Schleife definiert sein. Warum soll man die Schleife und die Definiton des dazugehörigen Zählers auseinanderreißen? Ich sehe da nun wirklich überhaupt keinen Vorteil darin. >> Python macht daraus ein einfaches: >> for abc in xyz: > > Das wiederum ist extrem unverständlich und auch genau so nicht > erwünscht. Verständlicher und vor allem kompakter geht es nicht. > Der Grund ist, daß man in einer for-Anweisung ja auch die Möglichkeit haben > will, dediziert auf das vorherige oder nächste Element zugreifen zu können. Ja, das ist tatsächlich unschön. In Python kann man das notfalls noch so machen:
1 | for index, abc in enumerate(xyz): |
Dann kann man per abc direkt auf das aktuelle Element zugreifen, aber auch den index nutzen, um auf benachbarte Elemente zugreifen. Ist zugegebenermaßen weniger elegant, aber immer noch recht klar und verständlich. > Und die Unverständlichkeit rührt aus der Mengenalgebra her: > if element in menge then tuwasdamit; > konkret: > if (Ch in ['0'..'9','.','-','+']) then ... > > aber genau DAS scheint mir bei Python eben nicht gemeint zu sein. Exakt das gibt es in Python auch.
1 | if e in M: |
Bedeutet: Für jedes Element in Menge M prüfe, ob es e entspricht. Oder anders ausgedrückt: Prüfe, ob e in M enthalten ist. Falls ja, tue folgendes.
1 | for e in M: |
Bedeutet: Für jedes Element e in Menge M tue folgendes. Was ist daran unverständlich? >> ... wobei in den meisten Fällen die Iterationsvariable ganz wegfällt, >> weil xyz selbst eine iterierbare Klasse ist und "selbst weiß, wie man >> sich aufzählt" > > Nö. Eine Objektklasse kann sich nicht selbst aufzählen. In Python schon, da Klassen selbst wiederum Objekte sind und man auch über alle Elemente eines Objekts iterieren kann. Aber es war ganz offensichtlich gemeint, dass die Klasse weiß, wie eine Instanz sich aufzählt.
Axel S. schrieb: > Persönlich mag ich Freiheit > lieber als Zwang. Auch wenn es der Zwang zu einem besonderen > Programmierstil ist, den jemand (oder meinetwegen auch die > Allgemeinheit) als besonders lesbar ansieht. In größeren Projekten bin ich für jeden „Zwang“ dankbar den eine Sprache bietet. Jedes im Wesentlichen belanglose Detail (wie Einrückung oder Groß-/Kleinschreibung von Klassen/Methodennamen) das von der Sprache festgelegt wird ist ein Detail weniger für das man Richtlinien schreiben, über das man in Code Reviews diskutieren oder neue Teammitglieder einweisen muss. Python, autopep8, mypy, google docstring guidelines, und man kann sich wirklich auf das wesentliche konzentrieren. Mit 50 Leuten an einem Projekt in Perl zu arbeiten, stelle ich mir z.B. die Hölle vor. Wahrscheinlich ist das sogar noch schlimmer wenn alle 50 davon Perl-Experten sind ;)
Rolf M. schrieb: > Klaus schrieb: >> Ich habe gültigen Code geschrieben. Der Sprachstandard und der Compiler >> haben daraus undefiniertes Verhalten gemacht. > > Das ist aber eine merkwürdige Ansicht. Du hast Code geschrieben, der > gegen den Standard verstößt, und nun erklärst du ihn zu gültigem Code > und beanstandest, dass der Standard ihn ungültig mache. Nein, so war das nicht gemeint. Ich habe compilierbaren Code (so meinte ich das "gültige") geschrieben, der aber undefined behavior hatte. Ist ja erlaubt. Der Standard verbietet mir ja nicht so etwas zu tun. War meine Blödheit/Vergesslichkeit nicht an das Verhalten zu denken. Aber es ging mir garnicht um die guten/schlechten Punkte in C. Mir ging es darum, ob Python mehr konkrete Vorgaben für die Interpreter/Compilerbauer macht als C, damit weniger undefiniertes Verhalten auftritt. > Das klingt fast, wie wenn sich jemand nach eine Wahlniederlage einfach selbst zum Gewinner erklärt. Für solche provozierenden Thesen habe ich keine Zeit. Muss Golf spielen gehen... :-)
Klaus schrieb: > Aber es ging mir garnicht um die guten/schlechten Punkte in C. > Mir ging es darum, ob Python mehr konkrete Vorgaben für die > Interpreter/Compilerbauer macht als C, damit weniger undefiniertes > Verhalten auftritt. Ich würde sagen, dass die Sprachdefinition allgemein schon viel weniger Raum dafür lässt. Es gibt z.B. keine Pointer, daher auch keine undefinierten Zugriffe darauf. int ist unbegrenzt, d.h. es gibt keine Integer-Promotion und es kann auch keine Überläufe geben. Ich würde sagen, dass ist bei interpretierten Sprachen meistens so. Da Performance sowieso nicht im Vordergrund steht, kann man auch mehr Checks einbauen, die undefiniertes Verhalten abfangen. Allerdings kann man von Python aus ja auch Module nutzen, die in C oder anderen Sprachen implementiert sind. In dem Fall kann das natürlich anders aussehen. >> Das klingt fast, wie wenn sich jemand nach eine Wahlniederlage einfach selbst > zum Gewinner erklärt. > Für solche provozierenden Thesen habe ich keine Zeit. > Muss Golf spielen gehen... :-) :)
W.S. schrieb: > Und bei Python gibt es so etwas überhaupt nicht. Dort müssen Blöcke > durch Einrückungen gekennzeichnet werden. > > Ich halte das für gequirlten Irrsinn. Programmiersprachen sollen > gefälligst klar lesbare Zeichen/Worte haben, um damit Blöcke zu > kennzeichnen! Aber hier bei Python haben wir stattdessen > unterschiedliche Anzahl von 'white space' Zeichen! Genau. Weil auch nur irgendeine Programmiersprache wegen ihrer Syntax verbreitet ist.
vn nn schrieb: > Genau. Weil auch nur irgendeine Programmiersprache wegen ihrer Syntax > verbreitet ist. Brainfuck? Als Sprache, nicht als Zustand!
Wo wir wieder bei einer mit religiösem Eifer geführten Diskussion über (Script-)programmiersprachen wären. Warum kann man nicht einfach mal akzeptieren, das andere eben eine eigene Meinung habe. Stattdessen wird die eigene Position zur einzig Wahren verklärt. Ich mag Python, ich entwickle damit unser HIL Testsystem, was mit integrierter automatischer C nach Python Konvertierung zum Einbinden externen Programmbibliotheken daher kommt, genauso wie ich damit vor Jahren beim DWD innerhalb von Sekunden große Satellitenkarten (numpy, matplotlib) berechnet/erstellt habe. Ist einfach ne tolle Sprache und wenn man erstmal das Konzept "alles ist eine Instanz" verstanden hat, dann macht es erst richtig Spaß. Und wenn ich halt mal was in Lua, Groovy oder auch Perl machen muss dann bekomme ich auch nicht gleich einen roten Kopf.
:
Bearbeitet durch User
Ich hätte eine Sprache, auf der man vereint und ersatzweise drauf rumhacken kann: PL/SQL Ich hätte damit Web-Anwendungen programmieren sollen. Da hab ich lieber gewechselt. WebObjects wollte der Chef nicht, das war ihm wohl zu genial.
Rolf M. schrieb: > Du konntest bisher auch leider nicht > darlegen, warum das ein Problem sein soll, außer weil du dann eben nicht > mehr kreuz und quer einrücken darfst. Ich habe überhaupt nicht von kreuz und quer einrücken geschrieben. Aber: Programmiersprachen bestehen aus Sprachelementen und diese müssen aus druckbaren Zeichen bestehen, eben weil es in Wirklichkeit keine Programmiersprachen, sondern Programmier-Schrift-Sprachen sind. Niemand spricht eine solche Sprache, sie werden alle immerzu nur geschrieben und dazu braucht es Zeichen. Nicht abgezählte Zwischenräume, sondern Zeichen bzw. Wörter. Die Zwischenräume gibt es üblicherweise nur dazu, zwischen den Zeichen/Wörtern zu trennen. ichschreibejaauchnichtallesohnezwischenräumeweil esindiesemfallekeinenblockzumarkierengibt. Eine Programmiersprache, die das Maß von Zwischenräumen ab Zeilenbeginn zu einem Sprachelement macht, verstößt damit frontal gegen obigen Grundsatz. Das ist dann nicht mehr formatfrei und es öffnet Fehlern und Mißverständnissen Tür und Tor. Beispiel space vor tab, was man selbst durch intensives Draufgucken nicht unterscheiden kann. Das ist genauso, als wenn man als Konvention herausgeben wollte, daß Marken in Spalte 1 und Ergibtanweisungen in Spalte 5 und if, then, else in Spalte 3 zu beginnen hätten. Vielleicht ist dieses Einrücken programmiertechnisch einfacher beim Schreiben des Python-Interpreters zu machen, als wenn man sich im Interpreter sowas wie { } begin end merken müßte. Aber das bedeutet, die Sache vom Standpunkt der Programmierers des Interpreters zu sehen und nicht vom Standpunkt des Benutzers der Programmiersprache. W.S.
Nick M. schrieb: > Ich hätte eine Sprache, auf der man vereint und ersatzweise drauf > rumhacken kann: PL/SQL Wenns danach geht: IBMs REXX. Eine Script-Sprache ohne Keywords: IF IF = THEN THEN DO END = NEAR END
:
Bearbeitet durch User
Nick M. schrieb: > Ich hätte eine Sprache, auf der man vereint und ersatzweise drauf > rumhacken kann: PL/SQL Im Zuge der Aussöhnung eigentlich eine gute Idee. Suchen wir mal ein Feindbild auf dem alle gemeinsam rumhacken können. Ich werf mal, aus aktuellem Anlass, JavaScript in die Runde. In der Backend-Entwicklung ein Graus, vor allem wenn man die Ausdrucksstärke von Python gewohnt ist. Beim Frontend, gemischt mit jQuery und MaterializeCSS eine absolute Katastrophe.
W.S. schrieb: > ichschreibejaauchnichtallesohnezwischenräumeweil > esindiesemfallekeinenblockzumarkierengibt. In FORTRAN geht das in Ordnung, Leerzeichen sind optional.
W.S. schrieb: > Aber: Programmiersprachen bestehen aus Sprachelementen und diese müssen > aus druckbaren Zeichen bestehen, eben weil es in Wirklichkeit keine > Programmiersprachen, sondern Programmier-Schrift-Sprachen sind. Offensichtlich nicht, da Python ansonsten nicht exisitieren könnte. Abgesehen gibt es eine UN Konvention oder Sonstiges, dass Whitespace nicht semantisch sein darf. W.S. schrieb: > Vielleicht ist dieses Einrücken programmiertechnisch einfacher beim > Schreiben des Python-Interpreters zu machen, als wenn man sich im > Interpreter sowas wie { } begin end merken müßte. Ganz sicher nicht - Es ist ein Haufen Logik notwendig um die richtige Einrückung trotz Space/Tab Verwechslungen herauszufinden. Ich stelle mir vor, dass irgendein Dozent angepisst war weil seine Studenten sich nicht um lesbare Einrückung gekümmert haben und dann Python erfunden hat um sie zu dahinzubringen. Ich weiß gar nicht warum hier gestritten wird. Offensichtlich funktioniert Python trotz oder gerade wegen dieser Eigenheit sehr gut. Wer es nicht mag soll es nicht benutzen - muss dann aber auch nicht behaupten, dass Whitespace-Semantik falsch oder schlecht sei.
dee schrieb: > Ich weiß gar nicht warum hier gestritten wird. Offensichtlich > funktioniert Python trotz oder gerade wegen dieser Eigenheit sehr gut. > Wer es nicht mag soll es nicht benutzen - muss dann aber auch nicht > behaupten, dass Whitespace-Semantik falsch oder schlecht sei. Und wenn ich Python grundsätzlich ganz gern mag, mit Klammern oder Keywords anstelle Whitespaces zur Blockkennzeichnung aber noch besser finden würde?
(prx) A. K. schrieb: > Nick M. schrieb: >> Ich hätte eine Sprache, auf der man vereint und ersatzweise drauf >> rumhacken kann: PL/SQL > > Wenns danach geht: IBMs REXX. Eine Script-Sprache ohne Keywords Eigentlich war ARexx auf dem Amiga ganz cool. Fast alle GUI-Programme hatten eine zusätzliche Script-Schnittstelle. Das hätte ich sehr oft gerne zurück.
Perl (also perl 5) ist zwar dafür berüchtigt dass evtl in 5 Jahre kein Mensch mehr den Code lesen kann. Bei vielen Alternativen ist es hingegen garantiert dass in 5 Jahren kein Interpreter den Code mehr lesen kann :) Eben weil an Perl schon lang genug gearbeitet wurde dass der Drang, alle Jahre mutwillig am Sprachkern herumzudoktern, inzwischen vergangen ist.
:
Bearbeitet durch User
Le X. schrieb: > Und wenn ich Python grundsätzlich ganz gern mag, mit Klammern oder > Keywords anstelle Whitespaces zur Blockkennzeichnung aber noch besser > finden würde? Dann mach doch ein Karl Klammer Mod ;) Man könnte aber auch sich darum bemühe eine Mehrheit zu finden und die Entwickler von Python von diesem Konzept mit Klammern zu überzeugen, wenn es einem wirklich so wichtig ist.
Le X. schrieb: > Und wenn ich Python grundsätzlich ganz gern mag, mit Klammern oder > Keywords anstelle Whitespaces zur Blockkennzeichnung aber noch besser > finden würde? Dann nimmt man Python with Braces: https://python-with-braces.appspot.com/
Egon D. schrieb: > DoS schrieb: > Mega grottig ist die "GUI-Fähigkeit" die ist auf dem Niveau von 1988. > > ??? > Du redest nicht etwa von "Tk"? Das ist nicht Python-spezifisch. Ich meine das TKInter, dass auch am häufigsten in Google hochblobbt wenn man Pyton und GUI als Suche eingibt. Das ist wie Grafiken Pixelweise mit Texteditoren zu erstellen. Das geht, ist aber nicht Stand der Technik. > Wenn ich das mit VisualBasic aus den 1990ern vergleiche, war das damals > besser gelöst. > > Komisch. Von VisualBasic für Linux habe ich nie etwas gehört... Kam ha auch von Microsoft, und die hatten ein gewisses Interesse an Windows als BS. Gibt es überhaupt was von Microsoft, das für Linux ist (außer ein Migrationstool Linux-> Windows)?
Hi Leute, das es bei einer Programmiersprache hier immer hoch her geht ist klar .... Vor vielen Jahren (ca. 15) hat mich die Formatierung auch erstmal genervt, da hab ich noch viel mit Perl gemacht. Aber die Zeit bleibt nun mal nicht stehen und gerade für Python gibt es sehr viele gute Libs die auch einfach eingebunden werden können. Seit geraumer Zeit verwende ich auch meist Python. Für eine GUI z.B. PyQt5. Klar, mit einem "vi" tut man sich da keinen Gefallen... Also, für Python-Projekte die Pycharm-IDE und für Java dann Netbeans oder Eclipse... my two cents ...
:
Bearbeitet durch User
W.S. schrieb: > Aber: Programmiersprachen bestehen aus Sprachelementen und diese müssen > aus druckbaren Zeichen bestehen Warum? Wo steht, dass Programmiersprachen die Formatierung von Text ignorieren müssen? Offensichtlich funktioniert es doch wunderbar. Python und andere Sprachen die das genau so machen, existieren und sind real. Also, warum müssen ausschließlich "druckbare" Zeichen verwendet werden? [Ein Leerzeichen ist "druckbar". Es kommt nur keine Tinte aufs Papier. So wie bei einem "O" die Fläche auch nicht gedruckt wird, sondern nur ein Kreis]
W.S. schrieb: > Rolf M. schrieb: >> Du konntest bisher auch leider nicht >> darlegen, warum das ein Problem sein soll, außer weil du dann eben nicht >> mehr kreuz und quer einrücken darfst. > > Ich habe überhaupt nicht von kreuz und quer einrücken geschrieben. Du hast es aber als Katastrophe dargestellt, dass es nur mit vernünftiger Einrückung geht. Daraus habe ich geschlussfolgert, dass du bevorzugst, kreuz und quer einzurücken, denn wenn du das nicht tust, könnte es dir ja wie mir egal sein. > Aber: Programmiersprachen bestehen aus Sprachelementen und diese müssen > aus druckbaren Zeichen bestehen, eben weil es in Wirklichkeit keine > Programmiersprachen, sondern Programmier-Schrift-Sprachen sind. Warum? Bei manchen Programmiersprachen (u.a. so ziemlich alle Assembler-Varianten) kann man auch Newlines nicht einfach setzen wo man will. Warum dürfen Elemente, die man zur optischen Gliederung des Code nutzt, nicht gleichzeitig auch zur logischen Gliederung dienen? Und nein, ein "weil man das halt nicht macht" reicht mir nicht. > Niemand spricht eine solche Sprache, sie werden alle immerzu nur > geschrieben und dazu braucht es Zeichen. Nicht abgezählte Zwischenräume, > sondern Zeichen bzw. Wörter. Auch für diese Aussage sehe ich keine Begründung. Warum braucht es das? > Die Zwischenräume gibt es üblicherweise nur dazu, zwischen den > Zeichen/Wörtern zu trennen. Das sieht für mich nach einer willkürliche Festlegung ohne technischen Grund aus. > ichschreibejaauchnichtallesohnezwischenräumeweil > esindiesemfallekeinenblockzumarkierengibt. > > Eine Programmiersprache, die das Maß von Zwischenräumen ab Zeilenbeginn > zu einem Sprachelement macht, verstößt damit frontal gegen obigen > Grundsatz. Das ist dann nicht mehr formatfrei und es öffnet Fehlern und > Mißverständnissen Tür und Tor. Beispiel space vor tab, was man selbst > durch intensives Draufgucken nicht unterscheiden kann. Wie schon gesagt: Die zu mischen, ist so oder so eine blöde Idee. Und Python weist einen per Fehlermeldung darauf hin. Mein Editor übrigens auch. > Vielleicht ist dieses Einrücken programmiertechnisch einfacher beim > Schreiben des Python-Interpreters zu machen, als wenn man sich im > Interpreter sowas wie { } begin end merken müßte. Aber das bedeutet, > die Sache vom Standpunkt der Programmierers des Interpreters zu sehen > und nicht vom Standpunkt des Benutzers der Programmiersprache. Ich glaube eher, dass es für den Interpreter schwieriger ist und dass es gemacht wurde, weil es für den Benutzer einfacher ist. DoS schrieb: > Kam ha auch von Microsoft, und die hatten ein gewisses Interesse an > Windows als BS. Gibt es überhaupt was von Microsoft, das für Linux ist > (außer ein Migrationstool Linux-> Windows)? Inzwischen so einiges. Und der überwiegende Teil der Microsoft-Cloud läuft unter Linux. Auch Microsoft musste einsehen, dass da kein Weg mehr dran vorbei führt. Vielleicht liegt's aber auch nur daran, dass Bill Gates nicht mehr so involviert ist. Der hatte Linux immer ziemlich auf dem Kieker. Ingo D. schrieb: > Klar, mit einem "vi" tut man sich da keinen Gefallen... Ja stimmt, besser vim mit YCM und noch dem einen oder anderen weiteren Plugin.
:
Bearbeitet durch User
DoS schrieb: > hochblobbt ... Grafiken Pixelweise Du hast von Tk soviel Ahnung, wie von der Rechtschreibung ;) leo
W.S. schrieb: > Vielleicht ist dieses Einrücken programmiertechnisch einfacher beim > Schreiben des Python-Interpreters zu machen, als wenn man sich im > Interpreter sowas wie { } begin end merken müßte. Nachdem ich schon einige Interpreter und Parser geschrieben hab: Nein, absolut nein. Kein normaler interpreter zählt whitespaces. Die whitespaces beenden ein token und werden dann konsumiert bis zum nächsten Zeichen. lc und cc (linecount und charactercount) braucht man höchstens für Fehlermeldungen, sonst sind die nur lästiges Beiwerk.
Manche Editoren können halbautomatisch anhand der Klammerebenen einrücken (zB emacs) - das entlastet den Kopf und bietet auch direkt eine Art fortwährenden Syntaxcheck. Und ist mit "klammerarmen" Sprachen nicht so gut möglich...
Andy D. schrieb: > Manche Editoren können halbautomatisch anhand der Klammerebenen > einrücken (zB emacs) Noch wilder! Die machen sogar eine geschlossene Klammer wenn man die zugehörige offene geschrieben hat. Natürlich sprachabhängig. Ich editiere soeben eine Datei mit der Endung .ml und Sublime weiss, was das sein soll. Und ich tippe '(' und dann steht da '()' und der Cursor steht auf dem ')'. Und mit der Endung .c nach einem '{<return>' rückt der auch richtig ein!!!!eins11elf Echt irre, was Editoren so können um Fehler zu reduzieren.
Irgendwer schrieb: > W.S. schrieb: >> Aber: Programmiersprachen bestehen aus Sprachelementen und diese müssen >> aus druckbaren Zeichen bestehen > > Warum? Weil man ja sonst nichts würde lesen können. Stell dir mal eine (hypothetische) Programmiersprache vor, bei der die Anzahl der Leerzeichen zwischen Zeilenanfang und Zeilenende unterschiedliche Bedeutungen hätte: 3 Stück: Zuweisung, 5 Stück: if, 1 Stück: while, garnix: goto. > Wo steht, dass Programmiersprachen die Formatierung von Text > ignorieren müssen? Müssen sie garnicht, aber sie müssen sich gefallen lassen, vom Publikum, dem sie zum Gebrauch angeboten werden, eingeschätzt zu werden in gute, mittelmäßige, schlechte und kotzmiserable Programmiersprachen. W.S.
W.S. schrieb: > Stell dir mal eine (hypothetische) Programmiersprache vor, bei der die > Anzahl der Leerzeichen Nicht so hypothetisch: https://en.wikipedia.org/wiki/Whitespace_(programming_language) leo
Rolf M. schrieb: > Du hast es aber als Katastrophe dargestellt, dass es nur mit > vernünftiger Einrückung geht. Daraus habe ich geschlussfolgert, Das war eine geradezu böswillige Unterstellung. Also nochmal zum Mitbuchstabieren: 1. Einrückungen sind zum gefälligen optischen Bild, wenn man sich die Quelle anschaut. 2. Blockbegrenzer (begin, end, {, }, oder sonstwas druckbares) sind für das klare Abgrenzen von Blöcken - sowohl für den Compiler als auch für den Leser. Ergo: Die Blockbegrenzer sind für die Richtigkeit, die Einrückungen für die Gefälligkeit beim Betrachter. So. W.S.
leo schrieb: > Nicht so hypothetisch O je. Es gibt doch wirklich nichts, das so bescheuert wäre, daß es nicht noch etwas NOCH BESCHEUERTERES gäbe. Naja: "Whitespace is an esoteric programming language"..... W.S.
Wenn Whitespace nichts ist - warum beschwert ihr euch gerade etliche Beiträge lang darüber?
W.S. schrieb: > Müssen sie garnicht, aber sie müssen sich gefallen lassen, vom > Publikum, dem sie zum Gebrauch angeboten werden, eingeschätzt zu werden > in gute, mittelmäßige, schlechte und kotzmiserable Programmiersprach Nein, der Nutzer muss einschätzen ob sein Problem mit dieserm Werkzeugt gut bearbeitbar ist. Die Diskussion ist immer die Gleiche. Ein Hammer ist super für einen Nagel. Scheiss Hammer, ich kann die Schraube nicht anziehen.... Oder wie beim Wein. Und wer der Spätburgunder noch so prämiert ist und alle trinken ihn nicht. Es ist nicht mein Fall. Ist er deshalb "schlecht oder kotzmiserabel"? Eine schlechte Programmiersprache wäre für mich eine, auf die man sich nicht verlassen kann. Erzeugt jedesmal andere Ausgaben...
W.S. schrieb: >> Nicht so hypothetisch > > O je. Es gibt doch wirklich nichts, das so bescheuert wäre, daß es nicht > noch etwas NOCH BESCHEUERTERES gäbe. Wie, soll das jetzt heißen, dass Whitespaces als Bestandteil der Syntax bescheuert wären? Also ich find die Idee witzig innerhalb eines Programms ein zweites unterzubringen. Sourcecode-Stenagographie!
Sorry für die Tippfehler: nochmal Oder wie beim Wein. Und wenn der Spätburgunder noch so prämiert ist und alle trinken ihn. Es ist nicht mein Fall. Ist er deshalb "schlecht oder kotzmiserabel"? Eine schlechte Programmiersprache wäre für mich eine, auf die man sich nicht verlassen kann. Erzeugt jedesmal andere Ausgaben...
Klaus schrieb: > Sorry für die Tippfehler: nochmal Tippfehler wurden beim Parsen aufgrund der Redundanz erkannt und korrigiert. Einrückungen und Zeilenumbrüche wurden ignoriert. Soll der korrigierte Text verwendet werden? J/N
W.S. schrieb: > 1. Einrückungen sind zum gefälligen optischen Bild, wenn man sich die > Quelle anschaut. Es gibt ziemlich viele Dinge in Programmiersprachen, die eigentlich nur für die gefällige Optik da sind, aber trotzdem semantische Bedeutung haben. Zum Beispiel Variablennamen. Den Rechner interessiert am Ende nur die Adresse, auf die er zugreifen muss. Klaus schrieb: > Eine schlechte Programmiersprache wäre für mich eine, > auf die man sich nicht verlassen kann. Erzeugt jedesmal andere > Ausgaben... Auch das lässt sich finden: http://p-nand-q.com/programming/languages/java2k/
Man dieser Thread ist ja schon fast bestes Comedy Gold. Zum Thema Einrückung kann man eigentlich nur folgendes sagen: Wenn ihr nicht sowieso schon eine gute IDE oder einen guten Editor benutzt, dann ist jetzt die Chance dies zu tun. BSP VSCode: Mit dem Python Plugin wird sofort ein Fehler angezeigt wenn man Tabs und Leerzeichen mischt, aber in den Einstellungen kann man auch gleich festlegen das beim druck auf die Tab-Taste einfach die vorgegebene Anzahl Spaces eingefügt (Standard 4). Auch das Plugin Pylance für VSCode ist sehr cool, den man kann live Typechecking bekommen (kein mypy Aufruf unbedingt mehr notwendig, ich benutzt es aber trotzdem noch), ergo während ich schreibe bekomme ich die Mitteilung, ob ich mir sicher bin eine Liste aus Integern an eine Funktion die einen String erwartet zu übergeben. (Funktioniert natürlich nur wenn man Code mit type hints benutzt, aber einige Bibliotheken tun dies, und auch der eigene Code profitiert davon.) Das macht zwar Python nicht typsicher, hilft einen aber den typischen "Montags morgen vor dem ersten Kaffee" Code zu überprüfen.
Irgendwer schrieb: > W.S. schrieb: >> Aber: Programmiersprachen bestehen aus Sprachelementen >> und diese müssen aus druckbaren Zeichen bestehen > > Warum? Weil umformatieren dann die Bedeutung nicht ändert -- und die Erfahrung lehrt, dass Text alle Nase lang aus den verschiedensten Gründen umformatiert wird. > Wo steht, dass Programmiersprachen die Formatierung > von Text ignorieren müssen? Wen interessiert, wo das steht? Die wichtige Frage ist, was sinnvoll ist.
Danke für da Feedback, Leo :-) Ich bin seit 41Tagen quasi ohne Schlaf (eine völlig neue Erfahrung). Wie ich die Zeilen geschrieben habe, hatte ich gerade eine Operation hinter mir und noch unter dem Einfluss der Narkose. Vielleicht siehst Du mir deshalb meine Fehltippereien nach. So was wird dir sicher nie passieren. Aber, wenn Du doch einmal auch über einen längeren Zeitraum bestialische Schmerzen hast, wirst Du Dich vielleicht an diese Zeilen erinnern.
Beitrag #6491987 wurde von einem Moderator gelöscht.
Beitrag #6492002 wurde von einem Moderator gelöscht.
Beitrag #6492015 wurde von einem Moderator gelöscht.
Walter T. schrieb im Beitrag #6492015:
> Nee, eigentlich kann man ganz sinnvolle Diskussionen führen.
Nee, man muss nur akzeptieren, dass dieser
Einrückungsvorschriftsschwachsinn einige extrem nervt (mich z.B.). Was
aber nicht heißt, dass die Leute gegen sauber strukturierten leserlichen
Quelltext sind. Ich persönlich hab die Einrückerei bei Spin (Propeller)
hassen gelernt und seitdem ist das Thema für mich erledigt (solang es
keiner im Beruf von mir fordert).
Eine Sprache steht und fällt mit ihren Bibliotheken. Da ist Python
sicherlich nicht deutlich schlechter / besser als all die anderen
Sprachen die Mainstream sind oder waren. Mal vom Ardoino abgesehen. :-)
Irgendwer schrieb: > Aber einem Menschen ist es nicht egal. In der Wahrnehmungspsychologie > ist es von oben bis unten durchgeforscht: Dein Hirn nimmt eingerückte > Strukturen deutlich schneller und einfacher wahr als verschachtelte > Klammern. Unsere ganze Schriftkultur besteht aus Blöcken und > Einrückungen. Richtig. Man kann die Sache ja mal von einer... höheren Ebene aus betrachten: wozu dienen in Sprachen wie Java, C, C++ und C# eigentlich die Klammern, in Pascal BEGIN und END und in Ruby das end? Genau: sie dienen ausschließlich dem Computer, damit er das Ende eines Blocks erkennen kann. Whitespace ist hier für den Compiler also völlig überflüssig, der Compiler braucht ihn nicht -- für den Compiler ist es gleichgültig, ob ich
1 | |
2 | for(int i = 0; i < 20; ++i) { |
3 | tuwas(i); |
4 | }
|
schreibe oder
1 | |
2 | for(int i=0;i<20;++i){tuwas(i);} |
Nur hinter der Deklaration der Variablen i ist ein Whitespace für den Compiler notwendig, damit er die beiden Token voneinander unterscheiden kann. Die Whitespaces dagegen, die jeder gute Entwickler trotzdem macht, dienen hingegen dem Menschen, indem sie die Les- und Wartbarkeit des Code deutlich verbessern. Da war es eine naheliegende und sinnvolle Idee, Whitespace für beides zu nutzen: einmal als Anweisung an den Compiler / Interpreter hinsichtlich der Blockgrenzen, und andererseits, wie gehabt, um die Les- und Wartbarkeit des Code zu verbessern. Eine Win-Win-Situation, sozusagen. ;-)
Andy D. schrieb: > Perl (also perl 5) ist zwar dafür berüchtigt dass evtl in 5 Jahre kein > Mensch mehr den Code lesen kann. Bei vielen Alternativen ist es hingegen > garantiert dass in 5 Jahren kein Interpreter den Code mehr lesen kann :) Das ist jetzt kein besonders gutes Beispiel, fürchte ich. Die Perl-Entwickler haben über zehn Jahre an Perl6 entwickelt, das jetzt seit 5 Jahren veröffentlicht ist. Da Perl6 allerdings nicht abwärtskompatibel ist, ist der allergrößte Teil der Welt noch mit Perl5 unterwegs, was die Perl-Entwickler vor die dumme Situation stellt, anstatt einer Perl-Version jetzt zwei pflegen zu müssen. Irgendwann werden sie in den sauren Apfel beißen müssen und Perl5 erst als deprecated und dann als EOL deklarieren, oder die Entwicklung von Perl6 einstellen müssen, um ihre Ressourcen zu konsolidieren. > Eben weil an Perl schon lang genug gearbeitet wurde dass der Drang, alle > Jahre mutwillig am Sprachkern herumzudoktern, inzwischen vergangen ist. Das ist ein weiterer Grund, warum Dein Beispiel nicht besonders glücklich gewählt ist. Perl6 bricht nämlich die Abwärtskompatibilität -- genauso übrigens wie der über viele Jahre vorbereitete und jetzt gerade (endlich) vollzogene Übergang von Python2 zu 3 -- und wird damit früher oder später genau die Probleme bekommen, von denen Du bislang noch glaubst, daß sie nur bei anderen Sprachen vorkommen.
DoS schrieb: > Egon D. schrieb: >> DoS schrieb: >> Mega grottig ist die "GUI-Fähigkeit" die ist auf dem Niveau von 1988. >> Du redest nicht etwa von "Tk"? Das ist nicht Python-spezifisch. > Ich meine das TKInter, dass auch am häufigsten in Google hochblobbt wenn > man Pyton und GUI als Suche eingibt. Das ist wie Grafiken Pixelweise mit > Texteditoren zu erstellen. Das geht, ist aber nicht Stand der Technik. Naja, wenn man es wenigstens ein kleines bisschen hübscher haben möchte, nimmt man nicht Tkinter, sondern dessen Erweiterung Tix. Die damit erstellten GUIs sind aber auch noch nicht so schick und so gut ins System integriert wie Qt & Co. Nebenbei angemerkt kann man mit Tkinter / Tix natürlich auch prima objektorientiert entwickeln, auch wenn die allermeisten Tutorials und Dokumentationen das leider nicht tun. Man muß nur wissen, daß man die super()-Funktion nicht benutzen kann, sondern stattdessen den Konstruktor __init__() der Elternklasse manuell aufrufen muß, weil die Tkinter- und Tix-Schnittstellen noch auf dem uralten Objektmodell von Python basieren, und deswegen leider nicht von object erben. > Gibt es überhaupt was von Microsoft, das für Linux ist > (außer ein Migrationstool Linux-> Windows)? Ja, einiges, zum Beispiel den SQL Server, VScode, Teams und Edge.
Andy D. schrieb: > Manche Editoren können halbautomatisch anhand der Klammerebenen > einrücken (zB emacs) - das entlastet den Kopf und bietet auch direkt > eine Art fortwährenden Syntaxcheck. Und ist mit "klammerarmen" Sprachen > nicht so gut möglich... Dann muß mein (GNU) Emacs eine geheimnisvolle Wunderversion sein, denn der kann das auch mit Python-Code. ;-)
W.S. schrieb: > Irgendwer schrieb: > Stell dir mal eine (hypothetische) Programmiersprache vor, bei der die > Anzahl der Leerzeichen zwischen Zeilenanfang und Zeilenende > unterschiedliche Bedeutungen hätte: 3 Stück: Zuweisung, 5 Stück: if, 1 > Stück: while, garnix: goto. Wir reden hier aber über Python, nicht über irgendwelche hypothetischen Strohpuppen, die Du Dir zusammenkonstruierst, um Deine "Argumentation" zu stützen. >> Wo steht, dass Programmiersprachen die Formatierung von Text >> ignorieren müssen? > Müssen sie garnicht, aber sie müssen sich gefallen lassen, vom > Publikum, dem sie zum Gebrauch angeboten werden, eingeschätzt zu werden > in gute, mittelmäßige, schlechte und kotzmiserable Programmiersprachen. Tja, und wie das mit dem lieben Publikum so ist: die einen fanden die Vorstellung toll, andere mittelmäßig, und einige wenige "kotzmiserabel". Sowas soll in einer pluralistischen Demokratie wie unserer sogar straffrei möglich sein! Im Hinblick auf Python befindest Du Dich offensichtlich bei einer verschwindenden Minderheit, denn wenn es wirklich "kotzmiserabel" wäre, dann wäre es weder die erfolgreichste und verbreitetste General-Purpose-Skriptsprache der Welt, noch würde es bei den Umfragen von StackOverflow seit vielen Jahre als "Most Wanted" genannt. Jetzt kann man natürlich gewisse Vermutungen anstellen, wessen Einschätzung wohl näher an einer "objektiven Realität" liegt: Deine, oder die des Restes der Welt. Mich deucht, daß Du darüber andere Ansichten pflegst als ich. ;-)
Sheeva P. schrieb: > Jetzt kann man natürlich gewisse Vermutungen anstellen, wessen > Einschätzung wohl näher an einer "objektiven Realität" liegt: Das provoziert doch nur die Antwort mit den Fliegen, notfalls ergänzt um Windows.
Nick M. schrieb: > Walter T. schrieb im Beitrag #6492015: >> Nee, eigentlich kann man ganz sinnvolle Diskussionen führen. > > Nee, man muss nur akzeptieren, dass dieser > Einrückungsvorschriftsschwachsinn einige extrem nervt (mich z.B.). Macht ja nichts, es zwingt einen niemand dazu. Aber die solcherart Genervten könnten dann in einem Thread, bei dem Gründe für die Beliebtheit einer Sprache diskutiert werden, einfach mal etwas tun, das ihnen aus völlig unerfindlichen Gründen extrem schwer zu fallen scheint: nämlich, einfach mal die Klappe zu halten. Ihr hättet doch einen eigenen Thread "warum finde ich Python so doof" aufmachen können, wenn es Euch ein unwiderstehliches Bedürfnis ist, anstatt diesen Thread mit Euren Vorurteilen zu verunstalten. Und ja, es sind größtenteils nichts weiter als Vorurteile, die die Python-Hasser hier vorzubringen vermögen. Wer diesen Thread vorurteilsfrei und objektiv liest, erkennt schnell: von denen, die Python tatsächlich benutzen, also: deren Urteil in ihrer eigenen praktischen Erfahrung fundiert ist, hat kein einziger ein Problem mit dieser Spracheigenschaft. Die Probleme existieren nur im Kopf von Leuten, die keinerlei Erfahrungen mit der Sprache haben. Also diesbezüglich vollkommen inkompetent sind, nichtsdestotrotz aber ihre engstirnigen Vorurteile für so wichtig halten, daß sie sie dem Rest der Welt mit aller Gewalt und gern mit verbalen und sozialen Entgleisungen ("Schwachsinn") aufzwingen müssen. Was wiederum mich persönlich zu der Vermutung bringt, daß diese Leute ganz andere Probleme haben als die Eigenschaften einer Sprache, die sie weder kennen noch benutzen, und die sie auch nicht kennenlernen oder benutzen wollen. > Was > aber nicht heißt, dass die Leute gegen sauber strukturierten leserlichen > Quelltext sind. Das ist der logische Umkehrschluß, fürchte ich. > Ich persönlich hab die Einrückerei bei Spin (Propeller) > hassen gelernt ... und hast wegen Deiner so gewonnenen Vorurteile also auch eine Erfahrungen mit Python. Ist ja nicht schlimm, aber: warum äußerst Du Dich dann in einem Thread, dessen Thema die Frage "warum ist Python so beliebt" ist? > Eine Sprache steht und fällt mit ihren Bibliotheken. Da ist Python > sicherlich nicht deutlich schlechter / besser als all die anderen > Sprachen die Mainstream sind oder waren. Gerade da ist Python den meisten anderen Sprachen weit voraus.
Sheeva P. schrieb: > ... und hast wegen Deiner so gewonnenen Vorurteile also auch eine > Erfahrungen mit Python. Ist ja nicht schlimm, aber: warum äußerst Du > Dich dann in einem Thread, dessen Thema die Frage "warum ist Python so > beliebt" ist? Lies einfach mal meine Beiträge durch. Dann wirst du dir das "Klappe halten" nochmal neu überlegen.
Nick M. schrieb: > Sheeva P. schrieb: >> Jetzt kann man natürlich gewisse Vermutungen anstellen, wessen >> Einschätzung wohl näher an einer "objektiven Realität" liegt: > > Das provoziert doch nur die Antwort mit den Fliegen, notfalls ergänzt um > Windows. ... die allerdings nur eine ziemlich billige Ablenkung wäre, nicht wahr?
Nick M. schrieb: > Sheeva P. schrieb: >> ... und hast wegen Deiner so gewonnenen Vorurteile also auch eine >> Erfahrungen mit Python. Ist ja nicht schlimm, aber: warum äußerst Du >> Dich dann in einem Thread, dessen Thema die Frage "warum ist Python so >> beliebt" ist? > > Lies einfach mal meine Beiträge durch. Dann wirst du dir das "Klappe > halten" nochmal neu überlegen. Jetzt habe ich Deine Beiträge alle noch einmal gelesen, sehe aber bislang keinen Anlaß, meine Position noch einmal zu überdenken. Könntest Du mir wohl bitte einen Hinweis darauf zukommen lassen, welches Deiner Postings einen Erkenntnisgewinn in Hinsicht auf die Ausgangsfrage des TO geleistet hat? Danke.
Sheeva P. schrieb: > ... die allerdings nur eine ziemlich billige Ablenkung wäre, nicht wahr? Was du scheinbar nicht wirklich mitbekommen hast in dem Thread: Hier vertritt jeder seine Meinung wie in einem Glaubenskrieg. Beinahe jedes Argument lässt sich leicht umdrehen durch Ersetzungen. Gerade du tust dich jetzt als oberster Krieger hervor. Du kannst es nicht ertragen, dass Leute die objektiv unsinnige Tab / Space Einrückung eben nicht mögen. Nein, du bist besser als die Nicht-Pythons weil du das toll findest. Ich zeig euch (damit sind beide Seiten gemeint) nur auf, wie löchrig eure Argumente sind. Wenn ich Vorteile davon hätte, würde ich mich Python anfreunden können. Hab ich keine, darum mach ich aktuell was, was Andere total blöd finden werden: Ich schau mir OCaml an. Weil das eine Sprache mit einem völlig anderen Konzept ist. Für mich ist Python "just another scripting language". Und wenn du im Thread das 6. posting liest, steht da, dass jeder Softwareentwickler eine Scriptsprache können muss. Weder hab ich da geschrieben, dass das unbedingt Python sein muss, noch dass es keinesfalls Python sein darf. Das Problem ist eher die völlige Verblendung der pro-Python-Leute. Denn ansonsten hätte der Beitrag keine -5 Punkte. Lies selbst! Nick M. schrieb:
Nick M. schrieb: > Walter T. schrieb: >> Nee, eigentlich kann man ganz sinnvolle Diskussionen führen. > > Nee, man muss nur akzeptieren, dass dieser Einrückungsvorschriftsschwachsinn > einige extrem nervt (mich z.B.). Aber auch, dass andere sich daran nicht stören und diese doch sehr emotionalen Reaktionen nicht nachvollziehen können. > Was aber nicht heißt, dass die Leute gegen sauber strukturierten leserlichen > Quelltext sind. Das ist dann wiederum das, was ich nicht verstehe. Warum stört man sich daran, dass die Sprache etwas erzwingt, das man doch sowieso macht?
Rolf M. schrieb: > Aber auch, dass andere sich daran nicht stören und diese doch sehr > emotionalen Reaktionen nicht nachvollziehen können. Kein Problem für mich. Manche mögen dicke Frauen, ich nicht. Aber emmotional ist daran nichts. Rolf M. schrieb: >> Was aber nicht heißt, dass die Leute gegen sauber strukturierten leserlichen >> Quelltext sind. > > Das ist dann wiederum das, was ich nicht verstehe. Warum stört man sich > daran, dass die Sprache etwas erzwingt, das man doch sowieso macht? **Räusper** Schalte bitte deinen Filter aus, wenn du die Gegenseite liest. Denn das wurde oft genug auf unterschiedliche Art und Weise erklärt. Und sieh das endlich ganz entspannt: Kaum einer (überhaupt jemand?) hat wirklich einen harten Grund genannt, warum Python untauglich ist. Python ist eine etablierte Sprache. Ich mag sie nicht, so wie C++ (das ich mal geliebt habe), oder Basic (damals gab es nichts anderes, als nächstes kam Pascal), oder Perl (da habich mal viel gemacht, bin aber immer wieder ins Schleudern gekommen), Assembler (es gibt C! Ausnahme 68000), you name it! Nick M. schrieb: > Es läuft immer nur auf einen Sprachen-Krieg raus. Genauso wie Atmel PIC > oder Arm. Kapiert?
W.S. schrieb: > Also nochmal zum Mitbuchstabieren: > 2. Blockbegrenzer (begin, end, {, }, oder sonstwas druckbares) sind > für das klare Abgrenzen von Blöcken - sowohl für den Compiler als auch > für den Leser. Ich hoffe Du Programmierst ausschließlich in Ada, Oberon und dergleichen. Also in Sprachen mit ENDIF, ENDFOR, END <function> usw. denn NUR mit solchen Blockbegrenzern wird klar welche Art von Blockabschluss gemeint ist. Mehrdeutige "END;"s (Pascal, M2), '}' (C*, Java), ')' (Lisp u.v.a.) bringen es einfach nicht, spätestens nach einer Refactoring-Session welche sich gewaschen hat. Das (back-)tracking dieser IST aufwändiger als das bisschen Einrücken von Py.Programmiersprachentheaterintendant
Nick M. schrieb: > Sheeva P. schrieb: >> ... die allerdings nur eine ziemlich billige Ablenkung wäre, nicht wahr? > > Was du scheinbar nicht wirklich mitbekommen hast in dem Thread: > Hier vertritt jeder seine Meinung wie in einem Glaubenskrieg. Was Du scheinbar nicht wirklich mitbekommen hast: genau das habe ich kritisiert und angelegentlich kritisch angemerkt, daß dieser Thread qua seiner Ausgangsfrage nicht der richtige Ort ist, seine Abneigungen zu erbrechen. > Gerade du tust dich jetzt als oberster Krieger hervor. Du kannst es > nicht ertragen, dass Leute die objektiv unsinnige Tab / Space Einrückung > eben nicht mögen. Das können die Leute meinetwegen gerne halten, wie sie wollen. Ob sie Python nutzen oder es hassen, ist mir vollkommen gleichgültig und insofern nicht mein Punkt. Mein Punkt ist, warum die Hasser ausgerechnet einen Thread hijacken und zumüllen müssen, in dem es NICHT um persönliche (Vor)Urteile und NICHT um die Frage geht, ob Python so beliebt ist, SONDERN um die Frage, WARUM es so beliebt ist. > Für mich ist Python "just another scripting language". Das stimmt ja auch, liefert aber keine Antwort auf die Frage des TO, warum Python so beliebt ist. Um ganz genau zu sein, hat es nichteinmal einen Bezug zu der Frage. > Lies selbst! > Nick M. schrieb: Äh... was jetzt genau?
Nick M. schrieb: > Ich schau mir OCaml an. Weil das eine Sprache mit einem völlig > anderen Konzept ist. Die Einstellung gefällt mir. "A language that doesn't affect the way you think about programming, is not worth knowing." Ich verstehe nicht warum einige der Meinung sind, dass sie mit ihren C++, Java und C#-Kenntnissen drei Programmiersprachen beherrschen. Aus meiner Sicht ist das nur eine ;-) Python ist halt eine gute Matlab // Mathematica // etc. Alternative. Außerdem machen die ihre Angebote gleich sehr attraktiv (wie bei Rust). Da gibt es eigene Webseite mit Tutorials, kostenlosen Büchern, kostenlosen IDE's und Plugins für für verschiedene Editoren // IDE's. Es werden STÄNDIG neue Bücher veröffentlicht. Neue Libs werden geschrieben / portiert. Und, und, und. Was zu Python pro Monat an Materialen rauskommt, liefert C doch in 5 Jahren nicht ;-)
Sheeva P. schrieb: > daß dieser Thread qua > seiner Ausgangsfrage nicht der richtige Ort ist, seine Abneigungen zu > erbrechen. Wo hab ich das gemacht? Sheeva P. schrieb: > Äh... was jetzt genau? Einfach auf den Link klicken. Mehr werde ich dir nicht vorkauen, denn dir fehlt es ganz offensichtlich an Objektivität.
Nick M. schrieb: > Rolf M. schrieb: >> Aber auch, dass andere sich daran nicht stören und diese doch sehr >> emotionalen Reaktionen nicht nachvollziehen können. > > Kein Problem für mich. Manche mögen dicke Frauen, ich nicht. > Aber emmotional ist daran nichts. Klar -- weswegen Du es auch gleich mal als "Schwachsinn" bezeichnen mußt. Weil Du (als einziger hier im Thread) das ja alles so völlig unemotional siehst. Natürlich hättest Du schreiben können, daß Dir das mit den Einrückungen nicht gefällt, weil Dir die Erfahrung mit einer Sprache nicht gefallen hat, die das ähnlich macht. Aber Du mußtest stattdessen auf die Kacke hauen und das einfach mal als "Schwachsinn" abtun -- und behauptest jetzt, das sei alles ganz unemotional und alle (außer Dir, natürlich) würden hier einen Glaubenskrieg führen. > Rolf M. schrieb: >>> Was aber nicht heißt, dass die Leute gegen sauber strukturierten leserlichen >>> Quelltext sind. >> >> Das ist dann wiederum das, was ich nicht verstehe. Warum stört man sich >> daran, dass die Sprache etwas erzwingt, das man doch sowieso macht? > > **Räusper** > Schalte bitte deinen Filter aus, wenn du die Gegenseite liest. Denn das > wurde oft genug auf unterschiedliche Art und Weise erklärt. Sag' es doch einfach, anstatt Deinem Gegenüber zu unterstellen, es könne nicht lesen. Nebenbei ließe sich Rolfs großartige Frage noch erweitern um die Frage, warum sich hier irgendwelche Leute mit schärfsten Ausdrücken über eine Sprache echauffieren, die sie niemals genutzt haben und nicht nutzen wollen, weil sie sie hassen? > Und sieh das endlich ganz entspannt: > Kaum einer (überhaupt jemand?) hat wirklich einen harten Grund genannt, > warum Python untauglich ist. Nein, einen solchen Grund hat keiner genannt, und abgesehen davon, daß es einen solchen Grund weder gibt (und bei einer so weit verbreiteten Sprache sicher auch nicht konstruiert werden kann), wären auch solche Aussagen hier deplatziert. > Python ist eine etablierte Sprache. Richtig. > Nick M. schrieb: >> Es läuft immer nur auf einen Sprachen-Krieg raus. Genauso wie Atmel PIC >> oder Arm. > > Kapiert? Nicht auch noch patzig werden, ja? Und: meine Anregung war und ist ja, einfach nur die Frage des TO zu beantworten, warum Python so beliebt ist. Zu einem Glaubens- und Sprachenkrieg machen das nur die Leute, die Python nicht kennen, es trotzdem aus irgendwelchen "Gründen" hassen und es deswegen offensichtlich nicht ertragen können, daß hier jemand etwas positives über die Sprache und seine Erfahrungen damit sagt.
schwäbisch oder sächsisch = immer noch deutsch schrieb im Beitrag #6492356: > Außerdem machen die ihre Angebote gleich sehr attraktiv (wie bei Rust). > Da gibt es eigene Webseite mit Tutorials, kostenlosen Büchern, > kostenlosen IDE's und Plugins für für verschiedene Editoren // IDE's. Es > werden STÄNDIG neue Bücher veröffentlicht. Neue Libs werden geschrieben > / portiert. Und, und, und. Dürfte man das ganz vorsichtig als Hype bezeichnen? Merkst du das nicht selbst, dass das einfach kein Argument ist zu sagen: Alle finden es toll. Klar gibt es aktuell weniger neue Bücher zu C. Das ist von 1972. Und es wurde fast schon alles von fast schon jedem gesagt. Bei Python muss halt fast jeder noch fast alles sagen. So kann er seine Bücher verkaufen, kann sich im I-Net profilieren und alle können sich gegenseitig bejubeln und über die Idioten herziehen die formatierungsabhängige Sprachen bekloppt finden. Ich glaub sogar, dass D. Knuth die auch bekloppt findet. Was mich aber nicht besser macht.
Nick M. schrieb: > Sheeva P. schrieb: >> daß dieser Thread qua >> seiner Ausgangsfrage nicht der richtige Ort ist, seine Abneigungen zu >> erbrechen. > > Wo hab ich das gemacht? Beitrag "Re: was ist das besondere an der programmiersprache Python?" > Sheeva P. schrieb: >> Äh... was jetzt genau? > > Einfach auf den Link klicken. Ach, daß es verschiedene Vorlieben gibt? Ein Allgemeinplätzchen ohne Aussagewert. > Mehr werde ich dir nicht vorkauen, denn dir fehlt es ganz offensichtlich > an Objektivität. Also muß man Python hassen, damit es für Dich hinreichend objektiv ist?
Und im Übrigen bin ich der Meinung, dass Karthago... ähm die Anzahl der
Programmiersprachen stark begrenzt werden soll.
Kann man nicht einen Interpreter für C++ schreiben, der Berechnungen wie
bei Matlab ermöglicht? Natürlich kann man das. Mit einer C++-Syntax.
dann sehen alle Schleifen / Vergleiche überall gleich aus.
Und nicht so, dass
- da schließe ich alle Anweisungen mit ; ab, hier aber nicht
- da begrenze ich die Funktionen durch {}-Klammer, hier aber durch die
Einrückung
- usw..
Das ist doch Schwachsinn! Die Schreibweise muss langsam vereinheitlicht
werden.
Die Informatiker sollen aufhören die Synthax zu verändern, sondern sich
an den Kern wagen.
Stellt euch vor die Mathematiker, Physiker, Chemiker und Ingeneure
würden für ihre Berechnungen unterschiedliche Zahlendarstellungen
benutzen! Der Turmbau zu Babel hat doch keine Zukunft.
Dutzende neue Sprachen pro Jahr - das ist krank.
Sheeva P. schrieb: > Nicht auch noch patzig werden, ja? Ja Glaubenskrieger! Python ist einfach die Sprache der Herrschenden. Alle Anderen sind unterlegen. Alahu Agbar! Sheeva P. schrieb: > Sag' es doch einfach, anstatt Deinem Gegenüber zu unterstellen, es könne > nicht lesen. So wirds wohl sein mit dem nicht lesen können, denn es wurde nachweislich mehrfach erklärt. Kann man aber überlesen, wenn man voller Hass auf die Andersgläubigen ist. Ansonsten wünsch ich besonders dir, oh großer Kämpfer für die einzige wahre Programmiersprache die erfolgreiche Niederschlagung all der Idioten die nicht deiner einzigen und gottgegebenen Sprache hörig sind die totale Welteroberung. Ich häng mich derweil im vorauseilenden Gehorsam untertänigst auf.
Beitrag #6492383 wurde von einem Moderator gelöscht.
schwäbisch oder sächsisch = immer noch deutsch schrieb im Beitrag #6492372: > Dutzende neue Sprachen pro Jahr - das ist krank. und jede hat andere Kommentarzeichen - zum kotzen https://de.wikipedia.org/wiki/Kommentar_(Programmierung)
Ich nutze Python schon seit über 20 Jahren, als die Sprache zwar schon
geraume Zeit existierte, aber noch weit entfernt vom Mainstream war.
Kurz: Ich war schon von Anfang an davon absolut begeistert, und seither
entwickelte sich Python fast nur zum Positiven. IMHO spielt die Sprache
inzwischen völlig zurecht in der obersten Liga und hat sich den Weg
dorthin langsam, aber stetig erkämpft. Von einem Hype kann da überhaupt
keine Rede sein.
Python hat eine ganze Reihe von Vorteilen, die in Kombination die
Sprache zu einer sehr runden Sache machen:
- Es ist leicht erlernbar:
- relativ geringer Sprachumfang
- einfache Syntax mit vielen "sprechenden" Schlüsselwörtern
- sozusagen das bessere und modernere Basic
- Es lässt sich interaktiv nutzen:
- auf die Schnelle etwas testen, ohne eine Quellcodedatei editieren
und kompilieren zu müssen.
- sehr vorteilhaft beim Erlernen der Sprache
- Es ermöglicht kurzen, knackigen und dennoch gut lesbaren Quellcode:
- wenig Redundanz (Boilerplate):
- durch dynamische Typisierung weitgehender Verzicht auf
Deklarationen
- Verzicht auf Blockklammern (korrekte Einrückung genügt)
- ausdrucksstark:
- häufig genutzte Container-Datentypen (List, Tuple und Dictionary)
sind fester Bestandteil der Sprache und werden durch syntaktische
Mittel stark unterstützt:
- List-Comprehensions
- mehrere Indizierungsmöglichkeiten
- Extraktion von Teilen der Container
- komfortables Entpacken in Einzelvariablen
- Iteration über Container-Elemente ohne Schleifenindex
- Lambda-Ausdrücke zur Inline-Definition einfacher
Callback-Funktionen u.ä.
- Generatoren erlauben u.a. die Entflechtung stark verschachtelter
Schleifenkonstrukte
- mächtige und dennoch leicht zu nutzende Standardbibliothek
- Es bietet gute Unterstützung bei der Integration von und in
sprachfremden Code:
- einfache Einbindung bestehender C-Bibliotheken in Form von shared
Libraries bzw. DLLs bspw. mit dem ctypes-Modul
- einfache Integration von Python in andere Programme, bspw. als
Scripting-Schnittstelle für Plugins
- Es gibt dafür sehr guten Support:
- umfangreiche Standardbibliothek
- gute und auch für Einsteiger verständliche Dokumentation
- große Community mit einer schier unendlichen Menge an weiteren
Bibliotheken
- evtl. auftretende Fragen und Probleme sind mit fast sicher schon auf
stackoverflow.com beantwortet bzw. gelöst worden
Das alles führt zu
- kurzen Entwicklungszeiten im Vergleich zu klassischen Sprachen wie
bspw. C++
- mehr Spaß beim Programmieren
Viele der genannten Vorteile treffen auch für andere Programmiersprachen
zu, aber keine der mir bekannten vereint sie alle unter einem Hut.
Diesen Vorteilen stehen natürlich auch einige Nachteile gegenüber:
- geringe Redundanz (s.o.) ist nicht nur ein Vorteil:
- viele Programmierfehler werden erst zur Laufzeit aufgedeckt und dort
manchmal erst nach längerem Einsatz -> systematischer Softwaretest
ist essentiell (sollte es aber auch in anderen Sprachen sein)
- das Fehlen von Blockklammern verhindert eine automatisierte
Neuformatierung bei kaputt gegangenen Einrückungen
- oft geringe Ausführungsgeschwindigkeit
- in der Standardimplementation nur ein Bytecode- aber kein
Native-Code-Compiler vorhanden
- im Vergleich zu vielen anderen Interpretersprachen recht schnell,
aber langsam im Vergleich zu kompilierten und statisch typisierten
Sprachen wie C++
- hardwarenahe und Echtzeitprogrammierung nicht bzw. nur sehr
eingeschränkt möglich
- durch leichte Rekompilierbarkeit des Bytecodes unzureichender
IP-Schutz
Für mich persönlich überwiegen die Vorteile von Python dessen Nachteile
in gefühlten 80% der von mir entwickelten Software bei weitem. Vielen
anderen Softwareentwicklern geht es wohl ebenso, sonst würde Python in
den Statistiken nicht so weit oben stehen.
Insbesondere die von einigen immer wieder lautstark hervorgebrachte
Kritik am Einrückungszwang ist für mich überhaupt nicht nachvollziehbar,
erst recht nicht, seit in Python 3 die Regeln für das Mischen von Tabs
und Spaces dahingehend verschärft wurden, dass – unabhängig vor der
Tab-Weite – die visuell wahrgenommene Blockstruktur immer auch der
syntaktischen entspricht. Von mir aus könnten die Tabs aber auch
komplett aus der Sprache verbannt werden. Auch Guido van Rossum hat wohl
mittlerweile eingesehen, dass – ähnlich wie in YAML – Tabs in Python nur
Kopfschmerzen bereiten und würde sie verbieten, wenn er die Sprache noch
einmal entwickeln würde.
Selbst wenn ich eine Software in C++ entwickle, nutze ich sehr oft
Python, um bei damit prototypisch erst einmal verschiedene Konzepte und
Algorithmen durchzuprobieren, bevor ich mich für eine bestimmte Option
entscheide. Dies spart am Ende Entwicklungszeit und führt zu qualitativ
besseren C++-Code, weil dieser dann sozusagen schon in der Version 2
vorliegt.
In Verbindung mit Numpy, Scipy und Matplotlib ist Python für mich auch
ein kostengünstigerer und flexiblerer Matlab-Ersatz. Bei numerischen
Algorithmen mit größeren Datenmengen, die auf Vektoren und Matrizen
abgebildet werden können, liegt damit die Ausführungsgeschwindigkeit
i.Allg. nicht arg viel niedriger als in C++.
Für Bildverarbeitung nutze ich intensiv die OpenCV-Bibliothek, die von
Hause aus C++ und Python unterstützt. Da im Bereich der Bildverarbeitung
naturgemäß viel experimentiert werden muss, kommen hier die Vorteile von
Python voll zum Tragen. Da fast alle rechenintensiven Operationen durch
die Bibliothek abgewickelt werden, ist auch hier die Geschwindigkeit
kaum unter der von C++. Stellt die OpenCV einen bestimmten Algorithmus
nicht zur Verfügung (was recht selten der Fall ist) und ist er auch mit
Numpy-Mitteln nicht effizient implementierbar, schreibe ich ihn in C
oder C++ und binde ihn als shared Library in das Python-Programm ein.
Schließlich verwende ich Python auch als hochentwickelten Taschenrechner
auf dem PC.
Python lässt sich auch als Plugin-Sprache in vielen Anwendungen (bspw.
Gimp, Inkscape, Vim usw.) nutzen und ist damit sozusagen das VBA für
Nicht-Microsoft-Anwendungen.
Vom Grundkonzept her ganz ähnlich zu Python ist die Sprache Ruby,
allerdings ist dort das Angebot an Bibliotheken und der Support durch
die Community nicht ganz so gut.
Bleibt noch Perl, das ebenfalls viele Dinge mit Python gemeinsam hat und
ebenfalls eine sehr große Community hat. Ein Vorteil von Perl gegenüber
Python ist die Integration von regulären Ausdrücken in den Sprachumfang
(in Python gibt es sie nur als Bibliothek). Das ist dann interessant,
wenn man viel Textanalyse machen möchte. Ansonsten ist mir Perl einfach
etwas zu altbacken, was sich bspw. in der Art und Weise äußert, wie
Funktionsargumente innerhalb einer Funktion entgegengenommen werden.
Rolf M. schrieb: > Das ist dann wiederum das, was ich nicht verstehe. Warum stört man sich > daran, dass die Sprache etwas erzwingt, das man doch sowieso macht? Du bist ein wenig starrsinnig, denn es wurde dir bereits mehrfach im Detail erklärt. Hier geht es um das Fehlen der Blockmarkierungen und den Ersatz selbiger durch das fehlerträchtige Maß von Einrückungen. W.S.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.