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?
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.
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.
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(inti=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.
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.
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!
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
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.
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.
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 🙄.
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.
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
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.
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.
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?
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 ...
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:
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
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++ ;-)
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.
> 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...
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.
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.
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).
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 :)
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
foriin1..2:
3
res=res+1
4
res=res+1
Pseudocode B:
1
res=0
2
foriin1..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.
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.
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
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.
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 ...
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.
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.
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.
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.
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(inti=0;i<20;++i){
3
tuwas(i);
4
}
schreibe oder
1
2
for(inti=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.
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.
Ich versuch’s mal mit dem Threadthema:
osman schrieb:> Kann jemand erklären, was ist das besondere an der programmiersprache> Python?
Es ist eine einfache, leicht zu erlernende und leicht zu lesende, dabei
aber umfassend ausgestattete, Sprache. Die Doku ist ausgezeichnet,
alleine schon mit dem Tutorial auf deren Seite kann man ziemlich schnell
ziemlich beeindruckende Sachen erstellen. Ziemlich gute IDEs, die dabei
unterstützen, (z.B. Pycharm) sind verfügbar; es gibt aber auch ein
shellartiges CLI mit Syntaxhighlighting und Autocomplete (ipython). Die
meisten Editoren mit Fokus auf das Programmieren/Scripten bringen
Funktionalität zur Nutzung von Python mit.
Schnittstellen zu den großen UI-Toolkits (Gtk, Qt) sind vorhanden und
ausgereift, so dass man auch mit wenig Aufwand grafische Programme
schreiben kann. Schnittstellen zu den verbreiteten DBMS sind ebenfalls
vorhanden, selbst ein integrierter Webserver fehlt nicht.
Virtuelle Environments und ein integriertes Paketmanagementsystem mit
schier grenzenloser Auswahl machen es extrem einfach, sich ein Setup für
ein konkretes Projekt zusammenzustellen, ohne an der eigentlichen
Installation rumpfuschen zu müssen.
Der größte Posten des Preises für das alles, und viel mehr, ist der
Ressourcenverbrauch und die geringe Ausführungsgeschwindigkeit. Um das
zu kompensieren, kann man auf Schnittstellen zu C/C++ zurückgreifen, und
zeitkritische oder auf andere Art rechenintensive Aufgaben etwa als
Module dahin auszulagern, um vom eigentlichen Programm aus bequem darauf
zuzugreifen. Auch gibt es Ansätze, mit denen sich Scripte kompilieren
lassen.
Typischerweise sind Pythonscripte gemessen an ihrer Funktionalität
extrem kurz, und bleiben dabei lesbar (ich habe damals™ einen modularen
IRC-Bot in weniger als fünfzig Zeilen implementiert, und konnte das nach
mehreren Jahren immer noch einwandfrei selbst lesen)
Bei all dem ist die Sprache weitgehend portabel, es ist also recht
einfach, Software damit zu erstellen, die sowohl unter Linux, als auch
unter Windows, als auch unter BSD, als auch unter MacOS läuft, als auch
unter AIX, als auch unter den anderen unter
https://www.python.org/download/other/ aufgeführten Systemen läuft.
Aufgrund der oben genannten Eigenschaften (und vielen mehr) hat sich die
Sprache weit verbreitet; es gibt eine riesige Community, in der man für
eigentlich jedes Problem Unterstützung bekommen kann.
schwäbisch oder sächsisch = immer noch deutsch schrieb im Beitrag
#6492356:
> Was zu Python pro Monat an Materialen rauskommt,...
Unsereiner kriegt pro Monat so ungefähr einen Zentner an Werbung ins
Haus. Meinst du, das ist relevant - mal abgesehen von all den dafür
abgeholzten Wäldern?
W.S.
19 Millionen können nicht irren. :-))
Google:
"python indentation" Ungefähr 19.800.000 Ergebnisse (0,51 Sekunden)
Yalu, dir widerspricht doch keiner grundlegend. Nur, was du sagst gilt
auch für andere Scriptsprachen. Einschließlich der Nachteile.
Ich ersetzte einfach Python mit Tcl und streich den Satz mit der
Einrückung. Ersetze ihn aber mit den schwachsinnigen Kommentaren in Tcl.
Das ist nämlich gleich dumm wie die Einrückung in Python.
Ich sags nochmal, auch wenn es der User Sheeva wieder geflissentlich
überliest: Es hängt im Wesentlichen davon ab, in welchen Umfeld du dich
bewegst ob Scriptsprache X oder Y besser ist (oder als besser empfunden
wird).
Ein Vergleich mit C, C++, Java ist nicht zielführend, weil das
compilierte Sprachen sind.
Nick M. schrieb:> 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?
Das kann man jederzeit unter diesem Aspekt betrachten, müßte aber bei
Python sehr schnell feststellen, daß das keineswegs ein Hype, sondern so
eine Henne-Ei-Sache ist. Eine fast dreißig Jahre alte
Programmiersprache, die sich im Laufe der letzten zehn, zwanzig Jahre
zur beliebtesten, verbreitetsten und erwünschten Sprache zu bezeichnen,
wird der Sache nicht gerecht, denn ein Hype (oder genauer: ein
Medienhype) ist doch gemeinhin eine eher kurzfristige Angelegenheit und
würde bedeuten, daß das solcherart "gehypte" ähnlich schnell wieder
verschwände, wie es aufgetaucht ist.
Python ist aber nicht schnell aufgetaucht, und seine Beliebtheit ist das
Ergebnis von vielen Jahren einer stetigen Entwicklung, während der es
sogar einige etablierte und eingesessene Platzhirsche wie Perl
verdrängt, andere wie PHP stark unter Druck und sich gegen Wettbewerber
wie Ruby durchgesetzt hat. Von einer Kurzfristigkeit, wie Du sie mit dem
Begriff "Hype" insinuierst, ist jedoch im Zuge der Entstehung der
aktuellen Situation -- wie gesagt: Python ist aktuell die beliebteste,
verbreitetste und meistgewünschte General-Purpose-Skriptsprache der Welt
-- also nichts zu sehen, und vom -- durch den Begriff "Hype" ebenfalls
unterstellten -- baldigen Abflauen des Aufwärtstrends von Python ist
bisher jedenfalls auch nichts zu erkennen.
Tatsächlich ist es aber so, daß Python nunmal aktuell die beliebteste,
verbreitetste und meistgewünschte General-Purpose-Skriptsprache der Welt
ist und es im Moment auch keinen einzigen Hinweis darauf gibt, daß sich
daran so bald etwas ändern wird. Diese Umstände haben Folgen, und zwar
vor allem, daß immer mehr Entwickler sich für die Sprache interessieren
und deswegen Bibliotheken dafür entwickeln. Andere schreiben Bücher
darüber und bieten Kurse, Tutorien oder anderes an.
Klar: wenn man sagen will, daß das nur die aktuelle Kuh sei, die durch
das Dorf getrieben werde, bald wieder verschwände, und es deswegen
unnötig sei, sich mit dem Thema zu beschäftigen: ja, dann kann man das
als Hype bezeichnen, vorsichtig oder auch unvorsichtig, ganz nach
Belieben. Aber wenn man das tut, wird man leider damit leben müssen, daß
es dem, was einen Hype ausmacht, nicht ansatzweise entspricht, und das
man deswegen Widerspruch erntet und eines Besseren belehrt wird.
Du sagst, Python sei "just another scripting language", und das simmt
natürlich auch. Wie jede andere Skriptsprache hat es gewisse
Eigenschaften und Eigenarten, welche man gut -- für sich persönlich --
gerne oder schlecht finden kann. Aber das erklärt weder, warum Du es
unbedingt zu einem Hype kleinreden willst, noch seinen grandiosen
Erfolg, um den es -- langsam komme ich mir vor wie eine tibetanische
Gebetsmühle -- in diesen Thread geht. Verstehst Du, was ein Thema ist?
Außerdem ist Python ganz besonders stark in einem Bereich, den es
tatsächlich schon lange gibt, der aber in den letzten Jahren besonders
populär geworden ist und daher schon eher den Kriterien eines Hype
entspricht. Nämlich der Verarbeitung, Analyse und Visualisierung von
Massendaten, Stichworte: Big Data, Machine Learning, und Data Science.
Und weil in den letzten Jahren immer mehr Anwendungsfälle den Weg in die
praktische Anwendung gefunden haben und aktuell vielle Entwicklungen
sowohl in der Wissenschaft, als auch in der Industrie und dem OSS-Umfeld
stattfinden, gewinnt auch das damit eng verbundene Python weitere hohe
Aufmerksamkeit, die ihm und seiner weiteren Verbreitung natürlich
ebenfalls zuträglich ist.
Du hast etwas weiter oben geschrieben, eine Sprache stünde oder fiele
mit ihren Bibliotheken. Auch das ist richtig, und genau das einer der
wichtigsten Gründe für den großen Erfolg von Python. Tatsächlich ist es
umgekehrt aber genau diese große Vielfalt an leistungsfähigen,
ausgereiften, aufeinander abgestimmten Bibliotheken (nebst weiteren
Tools), die wesentlich zum enormen Erfolg von Python beitragen und
zweifellos auch dafür sorgen, daß es kein Hype war, ist, oder wird. Und
dabei ist es vor allem die Vielfalt von gut aufeinander abgestimmten
Bibliotheken, die Pythons allergrößte Stärke darstellt.
Vergleichbare Sprachen sind in der Regel nur in einer Domäne stark, PHP
und Ruby zum Beispiel für die Webentwicklung. Es gibt zwar
GUI-Frameworks und auch Bibliotheken für die Datenanalyse für diese
beiden, aber nichts davon ist auch nur im Ansatz so ausgereift wie die
verfügbaren Erweiterungen für Pyton. Perl ist zwar ein echter
Allrounder, tut sich aber wie Ruby keinen Gefallen damit, Regular
Expressions in den Sprachkern zu integrieren und Sonderzeichen zur
Variablenauszeichnung zu benutzen, was die Lesbarkeit des Quellcode
einschränkt.
Die Antwort mancher Entwickler auf die verschiedenen Stärken und
Schwächen ihrer Sprachen bringen manche Entwickler dazu, sich für jede
Problemstellung und jeden Anwendungsfall eine eigene Sprache, deren
eigene Infrastrukturen, und eine eigene IDE anzueignen. Klar, das kann
man so machen.
Mein Ansatz hingegen ist ein anderer: ich suche mir darum eine Sprache,
die alles, was ich heute oder (soweit absehbar) in Zukunft machen
möchte, gleichermaßen sehr gut beherrscht. Genauso wie ich einen Editor
(oder einen Editor mit eingebauten Betriebssystem und eigener
Programmiersprache, oder eine IDE) benutze, der mit dieser und mit allen
anderen Sprachen gleichermaßen gut umgehen kann.
Ich habe meine Wahl getroffen. Meine Skriptsprache hieß früher Perl,
heute heißt sie Python, und mein Editor / IDE heißt GNU Emacs. Damit bin
ich äußerst zufrieden, die Arbeit damit ist produktiv und macht mir
erfreulicherweise zudem auch noch Spaß. Wer das nicht mag, soll eben was
anderes nehmen. Muß ich das verstehen? Nein. Muß ich es akzeptieren?
Aber ja, natürlich -- schon weil es mich nichts angeht. ;-)
Nick M. schrieb:> Sheeva P. schrieb:>> Nicht auch noch patzig werden, ja?>> Ja Glaubenskrieger! Python ist einfach die Sprache der Herrschenden.> Alle Anderen sind unterlegen.> Alahu Agbar!
Schon lustig, wie angepiekt Du auf sachlichen Widerspruch reagierst.
> Kann man aber überlesen, wenn man voller> Hass auf die Andersgläubigen ist.
Da muß ich mich auf Dein geschätztes fachmännisches Urteil verlassen,
damit kenne ich mich nicht aus und lege auch keinen Wert darauf,
Erfahrung damit zu sammeln.
> Ich häng mich derweil im vorauseilenden Gehorsam untertänigst auf.
Laß mal, hinterher muß irgendein bedauernswerter Mensch die Sauerei
wegmachen. Mir persönlich würde es schon reichen, wenn Du endlich einmal
anfangen würdest, Dich wie ein Erwachsener zu benehmen und sachlich zu
diskutieren, statt immer wieder mit diesen kindischen Ausfällen zu
nerven in der Hoffnung, das würde mich beeindrucken.
Yalu X. schrieb:> [...]
Wow, ein hervoragener Beitrag, der die Frage des TO vollständig
beantwortet und es auch ansonsten perfekt auf den Punkt bringt. Danke!
Fast jeder kann Python schreiben, lesen quasi jeder, der man
programmiert hat. Es ist extrem breit gefächerten, von einfachem Glue
code über dicke Maschinen Lernen libs zu guter Visualisierung und GUI
Anbindungen.
Jeder Entwickler sollte ne Skriptsprache können imo, Python ist da
einfach gut geeignet, weil man (im Gegenzug zur Standard bash zb) auch
komplexer werdenden Probleme schön in den Griff bekommt. Habt immer die
Praxis im Hinterhof! Fast alle ci/cd Umgebungen unterstützen Python, es
gibt bereits fertige Module für Anbindungen zu gitlab, bitbucket,
GitHub, egal was du willst.
Auf Geschwindigkeit kommt es fast niemals an.
PS, stark typisieren kann man mittlerweile per pypy auch.
Für scientific computing gucke ich mir aber gerade Julia an. Auch sehr
interessant :)
Sheeva P. schrieb:> Yalu X. schrieb:>> [...]>> Jack V. schrieb:>> [...]
Wow, zwei hervorragende Beiträge, die die Frage des TO vollständig
beantworten und es auch ansonsten perfekt auf den Punkt bringen. Danke!
Sheeva P. schrieb:> Du sagst, Python sei "just another scripting language", und das simmt> natürlich auch. Wie jede andere Skriptsprache hat es gewisse> Eigenschaften und Eigenarten, welche man gut -- für sich persönlich --> gerne oder schlecht finden kann.
Und jetzt? Hab ich jemals was anderes gesagt?
> Aber das erklärt weder, warum Du es> unbedingt zu einem Hype kleinreden willst,
Ich will es nicht kleinreden. Und verdammt nochmal LIES was ich
geschrieben hab. Und zwar bis zum Ende des jeweiligen Beitrags. Und pick
nicht den einzigen Satz dabei raus, der dir, oh du großer Evangelist der
besten und einzigen Programmiersprache ...
> langsam komme ich mir vor wie eine tibetanische> Gebetsmühle -- in diesen Thread geht.
Keine Angst, du bist was du bist. Ein Leierkasten (muss nicht aus Tibet
sein), der nur seine Meinung zulässt und die wahre Sprache gefunden hat.
Stehst du auch immer an der gleichen Ecke und hältst den Wachturn der
wahren Sprache Python hoch?
Ich bin nur ein kleiner Sünder. Ja eine Hure sogar, die die Sprache
verwendet die ihm gerade gefällt.
Lass mich mal aufzählen:
Basic, Pascal, Modula-2, Oberon, Eiffel, C, C++, ObjC, Fortran, Div.
Assembler, Tcl, Perl, fehlen bestimmt noch paar. Das heißt nicht, dass
ich die Sprachen noch kann! Ich bin kein Genie.
> Verstehst Du, was ein Thema ist?
Nö! Du?
Warum regst du dich den (nach deinen Regeln) anhaltend völlig offtopic
über andere Meinungen auf?
> Ich habe meine Wahl getroffen.
Andere auch.
> Meine Skriptsprache hieß früher Perl,
Meine auch. Aber vorher AWK.
> heute heißt sie Python,
Meine Tcl
> und mein Editor / IDE heißt GNU Emacs.
Je nachdem, aufm Mac eigentlich immer Sublime, auf Win oft Notepad++
oder halt der Editor von MPLAB X oder Quartus. Ich bin da nicht so
verbohrt. Ist mir eher wurst, alle taugen was und manchmal nehm ich halt
den ganz speziellen, der das als einziger kann. Ist wie mit den Sprachen
oder den Prozessoren. Wenn mir was zu schwachsinnig ist, nehm ich was
mit erträglichen Schwachsinn.
Ist aber auch völlig egal, welchen Editor du verwendest, welch
Scriptsprachen du nicht mehr magst und wie es dazu gekommen bist, dass
du dich für etwas entschieden hast. Das gibt schon so viele
Permutationen, dass es reichlich wenig werden die dir unabdingbar
zujubeln werden.
Der Rest deines Neuen Testaments ist wohl nicht lesenswert. Zumindest
waren deine Vorherigen Posts schon zweifelhaft genug.
Nick M. schrieb:> Yalu, dir widerspricht doch keiner grundlegend.
Das würde ich auch keinem raten ;-)
> Nur, was du sagst gilt auch für andere Scriptsprachen. Einschließlich> der Nachteile.
Nur dass IMHO Python mehr Vorteile und weniger Nachteile in sich vereint
als andere Programmiersprachen. Dennoch ist natürlich auch Python nicht
perfekt, und was für den einen ein Vorteil ist, kann von einem anderen
als Nachteil wahrgenommen werden.
> Ich ersetzte einfach Python mit Tcl und streich den Satz mit der> Einrückung. Ersetze ihn aber mit den schwachsinnigen Kommentaren in Tcl.> Das ist nämlich gleich dumm wie die Einrückung in Python.
Naja, zumindest die Syntax von Tcl ist im Vergleich zu Python ja schon
ziemlich primitiv und unelegant. Sie erinnert mich stark an eine
Shell-Sprache, mit ich ungern größere Softwareprojekte realisieren
würde, auch wenn das prinzipiell natürlich möglich ist.
Aber das ist natürlich bis zu einem gewissen Grad Geschmackssache.
Weiter oben schrieb ja jemand, dass er auch Python nicht für große
Projekte geeignet hält.
> Ich sags nochmal, auch wenn es der User Sheeva wieder geflissentlich> überliest: Es hängt im Wesentlichen davon ab, in welchen Umfeld du dich> bewegst ob Scriptsprache X oder Y besser ist (oder als besser empfunden> wird).
In diesem Punkt sind wir einer Meinung. Ich wollte mit einem obigen
Beitrag Python auch nicht als die objektiv beste Programmiersprache
propagieren, sondern die Vorteile aufzählen, die vermutlich der Grund
für die ständig steigende Akzeptanz der Sprache sind.
> Ein Vergleich mit C, C++, Java ist nicht zielführend, weil das> compilierte Sprachen sind.
Warum nicht?
Solange ein Programm tut, was es soll, und ausreichend flüssig läuft,
interessiert es mich als Entwickler wenig und den Anwender überhaupt
nicht, ob der Quellcode direkt interpretiert wird, vorher in einen
Bytecode übersetzt wird, zur Laufzeit vielleicht noch einen JIT-Compiler
durchläuft oder direkt in Native-Code übersetzt wird.
Als es für Java noch keinen JIT-Compiler gab, wurde – genauso wie in
Python – der Quellcode beim Entwickler in Bytecode kompiliert, der dann
beim Anwender durch einen Bytecode-Interpreter ausgeführt wurde.
Mittlerweile kann sowohl Java als auch Python in Nativ-Code überführt
werden. Insofern ist die Kompilierbarkeit kein Kriterium für die
Sinnhaftigkeit des Vergleichs zwischen zwei Programmiersprachen.
Für mich besteht zwischen C++ und Python durchaus ein Konkurrenzkampf,
der in meiner kleinen Welt nicht immer, aber immer öfter von Python
gewonnen wird.
Yalu X. schrieb:> Warum nicht?
Weil compilierte Sprachen vorher einen Check machen können. In
Scriptsprachen kann man genialen Unsinn anstellen. Der entweder als
Unsinn endet, oder tatsächlich genial ist.
In Tcl sieht das bsp. so aus:
1
procProc1{num}{
2
puts"Proc $num"
3
}
4
5
procProc2{num}{
6
puts"Proc $num"
7
}
8
9
for{seti1}{$i<3}{incri}{
10
Proc$i$i
11
}
Die Schleife wird Proc1 und Proc2 aufrufen.
Genauso kann man auch auf Variablen zugreifen. Und so ein typloser
zusammengepappter Code lässt sich zur Compilezeit nicht überprüfen.
Daher der Punkt in deiner Nachteils-Liste mit den Fehlern.
Genau daher mag ich Skriptsprachen. Aber gleichzeitig kann man sich
damit ganz elegant ins Bein schießen. Wenn sowas im Hause bleibt, ist
das kein Problem. Warum das aber ausgeliefert ein übler Angriff gegen
die eigene Firma sein kann versuch ich nicht nochmal zu erklären.
Zu deinen anderen Punkten hab ich nicht wirklich was zu widersprechen.
[Anm. d. Mod.: geloescht]
Sheeva P. schrieb im Beitrag #6492505:
> Trotzdem muß ich> widersprechen, denn: einer meiner wesentlichen Gründe für die Wahl von> Python war, daß es eben tatsächlich ein starker Allrounder ist. Ohne> Python würde ich Meß- und Massendaten wohl mit R verarbeiten, meine> Automatisierungen (immer noch) in Perl machen, FatClient-GUIs in C++ mit> Qt oder ebenfalls Perl, und Webapplikationen mit PHP oder Ruby (on> Rails) entwickeln.
Hättest alles auch mit Tcl/Tk machen können. Das heißt aber weder das
Eine, noch das Andere.
Sind halt nur wieder ein Haufen Wörter von dir die letztendlich kein
Argument sind. Weder für das Eine nach das Andere.
Oder soll ich jetzt den Code für meinen LXI-Abfrage hier posten um
irgendwas zu belegen. Wäre aber mit Tcl/Tk und hat hier nichts verloren.
Hypothetisch:
Mit den LXI-Daten bereite ich dann eine Datei für GNU-Plot auf und ruf
dann Gnuplot auf. Also ist da auch gleich Automatisierung dabei. UI ist
mit Tk.
[Anm. d. Mod.: geloescht]
Sheeva P. schrieb im Beitrag #6492505:
> Aber zum Glück muß ich das nicht.
Eben. Darum braucht wir EINE Programmiersprache für alles.
Und Python ist dafür natürlich nicht geeigent ;-)
Yalu X. schrieb:> Naja, zumindest die Syntax von Tcl ist im Vergleich zu Python ja schon> ziemlich primitiv und unelegant.
**SCHNIPP**
> Aber das ist natürlich bis zu einem gewissen Grad Geschmackssache.
Ja, was sag ich dazu?
**Schulterzucken**
Dir gefällt die Syntax nicht, ich finde sie anfangs verwirrend und daher
eine Herausforderung. Ist schon ziemlich gaga was man in Tcl in einer
Zeile schreiben kann. Das hat aber auch damit zu tun, ob man leserlichen
code schreiben will oder nicht. Ist wie mit C und dem Obfuscated
C-Contest. Was da rauskommt versteh ich nicht, will ich aber auch nicht
verstehen. Ist mir zu mühsam. Andere finden es lustig. Auch OK.
Ich finde sowas leserlich, so schreib ich Tcl
[Anm. d. Mod: Abschnitt geloescht]
> Sheeva P. schrieb im Beitrag #6492505:>> Trotzdem muß ich>> widersprechen, denn: einer meiner wesentlichen Gründe für die Wahl von>> Python war, daß es eben tatsächlich ein starker Allrounder ist. Ohne>> Python würde ich Meß- und Massendaten wohl mit R verarbeiten, meine>> Automatisierungen (immer noch) in Perl machen, FatClient-GUIs in C++ mit>> Qt oder ebenfalls Perl, und Webapplikationen mit PHP oder Ruby (on>> Rails) entwickeln.>> Hättest alles auch mit Tcl/Tk machen können. Das heißt aber weder das> Eine, noch das Andere.
Bestimmt hätte ich das, aber auch genauso komfortabel? Wenn ich mir nur
einmal die dankenswerterweise im Tcl-Wiki zusammengetragene Liste [1]
von Tcl-Entsprechungen für Module anschaue, die Python bereits
standardmäßig mitbringt, dann... äh... es mag sein, daß die Liste nicht
sehr gut gepflegt ist, aber...
Ich bin sicher, für fast alles, das es in Python gibt, findet man
irgendwie auch eine entsprechende Bibliothek für Tcl. Aber die muß ich
dann leider erst suchen, finden, und evaluieren. Oder ich muß mir eben
selbst etwas schreiben... äh, ja, leider Not Invented Here, und dann muß
ich's auch noch pflegen.
> Oder soll ich jetzt den Code für meinen LXI-Abfrage hier posten um> irgendwas zu belegen.
Du mußt hier gar nichts belegen.
> Mit den LXI-Daten bereite ich dann eine Datei für GNU-Plot auf und ruf> dann Gnuplot auf. Also ist da auch gleich Automatisierung dabei. UI ist> mit Tk.
Tjaaa, wie sage ich das jetzt, ohne daß Du es gleich wieder als Kreuzzug
verstehen willst? Zu den schönen Eigenschaften von Python gehört, daß
ich für so etwas keine externen Programme wie gnuplot brauche. Versteh'
mich nicht falsch, ich kenne und mag gnuplot, aber... wie auch Tk und
Tix sieht man seinen Ergebnissen leider auch das betagte Alter des
Werkzeugs an. Mir persönlich wäre das egal, aber mein Chef, nunja, der
ist bei so etwas leider ein bisschen komisch.
Außerdem macht Gnuplot aus den Daten leider nur eine einzelne statische
Grafik. Die Python-Library Pandas dagegen kann zwar auch statische
Dateien generieren, aber sie kann mir auch ein interaktives Fenster
öffnen, in das ich zum Beispiel hineinzoomen und bestimmte Bereiche
genauer anschauen kann. Oder sie erzeugt mir über Bokeh eine interaktive
Darstellung meiner Daten fürs Web. Vielleicht magst Du mal unter [2] in
einen anderen Thread schauen, wo ich mir den Spaß gemacht habe, ein
kleines Skript zur Auswertung der Lesenswert-Zähler je Autor zu
schreiben; da sind unten auch ein paar mit Pandas und Bokeh erzeugte
interaktive Plots zu finden.
[1] https://wiki.tcl-lang.org/page/Tcl+Equivalents+of+Python+Modules
[2] Beitrag "Re: Linux wird nicht wirklich akzeptiert, woran liegt das ?"
schwäbisch oder sächsisch = immer noch deutsch schrieb im Beitrag
#6492532:
> Sheeva P. schrieb im Beitrag #6492505:>> Aber zum Glück muß ich das nicht.>> Eben. Darum braucht wir EINE Programmiersprache für alles.>> Und Python ist dafür natürlich nicht geeigent ;-)
Das stimmt, wir müssen alle sofort zu Assembler wechseln. ;-)
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.
Ja, du bleibst in dem Thread sachlicher als manch anderer, wobei das
hier für mich schon emotional klingt:
Nick M. schrieb:> dass dieser Einrückungsvorschriftsschwachsinn einige extrem nervt (mich> z.B.).
Würdest du über dicke Frauen ähnlich sprechen, nur weil du die nicht
bevorzugst?
> 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.
Ich hab ja schon geschrieben, dass ich über ein "das macht man nicht.
Whitespace setzt man so nicht ein, basta!" hinaus nicht viel an
Argumenten finden konnte. Du bist da eher die Ausnahme mit dem Argument
des zur Fehlersuche temporär eingefügten Code, und ich habe ja
bestätigt, dass ich das auch als störend empfinde. Aber eben bei weitem
nicht so sehr, dass ich das ganze Konzept deshalb zum
"Einrückungsvorschriftsschwachsinn" degradieren würde.
> Nick M. schrieb:>> Es läuft immer nur auf einen Sprachen-Krieg raus. Genauso wie Atmel PIC>> oder Arm.>> Kapiert?
Das sowieso. Das zeigt aber auch, dass es oft nicht um harte Fakten,
sondern eher um Geschmackssache geht. Aber wenn jemand hier etwas als
Argument aufführt, das für mich keinen Sinn ergibt oder keine Begründung
hat, frage ich trotzdem nach.
Rolf M. schrieb:> Ja, du bleibst in dem Thread sachlicher als manch anderer, wobei das> hier für mich schon emotional klingt:>> Nick M. schrieb:>> dass dieser Einrückungsvorschriftsschwachsinn einige extrem nervt (mich>> z.B.).
Ist halt für mich Schwachsinn. Genauso wie die Kommentare in meinem
geliebten Tcl Schwachsinn sind. Ich bezeichne das gradraus als
Schwachsinn. Weil da jemand einfach nicht nachgedacht hat.
Die Deutschen sind doch bei den Amis dafür bekannt, dass sie deutlich
sind. Gilt das jetzt nicht mehr? Das ist Schwachsinn für mich, daher ist
aber nicht die komplette Sprache Schwachsinn. Das gilt für Tcl und für
Phython.
Aber nicht für Spin. :-))
Ich schreib es jetzt zum gefühlt 10ten Mal: Das endet nur in einem
Sprachenkrieg. Und genau so ist es. Es gibt leider paar komplett
Verbohrte die Python (oder sonst eine Sprache) als Religion ansehen.
Ich bin nicht mit einer Sprache verheiratet.
Es gibt paar Möglichkeiten.
Die Firma verlangt Python von mir, ich gewöhn mich dran.
Die Firma verlangt Python von mir, dann wechsle ich die Arbeit (hab ich
schon mal gemacht, nicht wg. Python)
Die Firma verlangt kein Python von mir, ich machs weil es mir gefällt.
Die Firma verlangt kein Python von mir, was bin ich glücklich!
Niemand verlangt Python von mir, darum mach ich Rubi.
Niemand verlangt Python von mir, dann trink ich lieber Bier.
Niemand verlangt Python von mir, mein Nachbar kanns, darum mach ich es
auch.
Niemand verlangt Python von mir, darum bin ich beim Ausprobieren bei Tcl
hängen geblieben.
Nieman verlangt Python von mir, aber ich find es Klasse!
Ich mach C, weils mir Spaß macht. Und weils mir Spaß macht, such ich mir
eine Arbeit die mir Spaß macht und wo ich das verwenden kann.
Genauso wie mir mal NewtonScript sehr viel Spaß gemacht hat und ich
auch eine Arbeit dafür gefunden hab. München-Starnberg kann man auch mit
dem Rad fahren. Und durch den Wald auch mit dem Mountainbike. Dann ist
der Spaß doppelt. Bis Steve Jobs den Newton von heute auf morgen den
Hahn abgedreht hat und mein Spaß ein Ende hatte. Aber ich kauf immer
noch Apple-Zeugs.
Leute, das ist alles in Ordnung. Und genau desshalb sind diese
Glaubenskriege hier alles andere als zielführend.
Was von den Mods bestätigt werden kann. ;-)) (Danke für die Geduld)
Das ist ja soweit schön und gut, allerdings:
Nick M. schrieb:> Weil da jemand einfach nicht nachgedacht hat.
sollte heißen: weil da jemand zu anderen Schlüssen gekommen ist, als du.
Sowas passiert, das ist kein Drama – aber denen dann unterstellen, dass
sie nicht nachgedacht hätten, im Umkehrschluss also sich selbst als den
Maßstab von allem darzustellen – das ist, mit Verlaub, für’n Arsch.
Rolf M. schrieb:>> Nick M. schrieb:>>> Es läuft immer nur auf einen Sprachen-Krieg raus. Genauso wie Atmel PIC>>> oder Arm.>>>> Kapiert?>> Das sowieso. Das zeigt aber auch, dass es oft nicht um harte Fakten,> sondern eher um Geschmackssache geht.
Äh, zum wiederholten Male: JA
Ich finde xxx Schwachsinn. Lies bitte mein Posting davor bezüglich Tcl
und Schwachsinn.
W.S. schrieb:> Hier geht es um das Fehlen der Blockmarkierungen und den Ersatz selbiger durch> das fehlerträchtige Maß von Einrückungen.
Wie schon gesagt halte ich es für weniger fehlerträchtig, weil die
Möglichkeit der Inkonsistenz zwischen Einrückung und Blockmarkierung
wegfällt. Aber nun gut, da mag es andere Meinungen geben.
Jack V. schrieb:> sollte heißen: weil da jemand zu anderen Schlüssen gekommen ist,
Tja, der Schöpfer der Sprache sieht das inzischen ja selbst schon nicht
mehr als so genial an.
Und wenn dich der Ausdruck "Schwachsinn" stört, dann nenn es halt "eine
äussert ungeschickte und kurzsichtige Entscheidung die auf lange Sicht
zu einem Umdenken führen wird"
Ehrlich, für mich ist das halt so, denn wer Sprachen entwirft, kennt
sicherlich auch andere Sprachen und deren Konzepte. Und wenn man mit
einem recht einfachen und gängigen Konzept bricht, dann muss man dafür
schon wirklich handfeste Argumente haben. Oder Starrköpfig sein.
Oder Revanchist? Jetzt ehrlich!
"Denen werde ich die Hammelbeine schon langziehen! Die werden die
Einrückungen 4 Leerzeichen machen, weil ein Tab immer 4 Leerzeichen
sind. Und damit die das kapieren, dürfen LZ und Tab nicht gemischt
werden. Jawollllll! <harharhar>"
Bei mir sind Tabs immer schon 2 LZ. Seit ich programmiere.
Und darum bezeichne ich das als Schwachsinn. Anderen gefällts. Ich mag
Mäuse nicht mal gebraten, die Katze frisst sie roh.
Rolf M. schrieb:> weil die> Möglichkeit der Inkonsistenz zwischen Einrückung und Blockmarkierung> wegfällt. Aber nun gut, da mag es andere Meinungen geben.
Da ist auch nichts inkonsistent, das liegt nur in deinen (lobenswerten)
ästhetischen Ansprüchen die dein (und erfreulicherweise auch mein)
Editor gerne sklavisch auf Tastendruck umsetzt.
Und jeder darf Einrücken und Zeileunumbrüche machen wie er mag und wann
er mag. Juhuuuuu
Rolf M. schrieb:> Würdest du über dicke Frauen ähnlich sprechen, nur weil du die nicht> bevorzugst?
Das würde der Mod dann völlig zu Recht löschen. ;-)
Bisher ausser Acht gelassene Besonderheiten, welche Python so beliebt
machen:
- es ist nicht C
- es kommt ohne Präprozessor
- es ist nicht Java
- es ist nicht Perl
- es ist gottlob nicht Tcl
- es verunmöglicht sowas wie IOCCC
- es vermeidet sowas wie MISRA
- hat nicht so viele Dialekte wie K&R, ANSI, POSIX, C89, C99,
ObjectiveC, C++, C#, usw.
- die Transition von 2 zu 3 ist wohl nicht vollständig aber hochgradig
automatisierbar dass Hilfsmittel dazu gleich mitgeliefert kommen
- es hat den bewährten "pep" der offensichtlich effektiv ist (anders als
ANSI oder wie das bei C/C++ heissen mag wo für alle Sonderlocken
lobbyiert werden kann und letztlich alles, aber auch gar ALLES, mit rein
kommt Hauptsache jedes Mitglied konnte eine Sonderlocke beitragen und
keiner der alten Zöpfe wird gestrichen)
Yalu X. schrieb:>> Nur, was du sagst gilt auch für andere Scriptsprachen.>> Einschließlich der Nachteile.>> Nur dass IMHO Python mehr Vorteile und weniger Nachteile> in sich vereint als andere Programmiersprachen.
Naja, leider scheint hier niemand ausreichend qualifiziert
(oder motiviert), mal einen SACHLICHEN Vergleich z.B.
zwischen Tcl und python vorzunehmen. Ich bin dafür nicht
geeignet -- ich kenne nur Tcl. Interessieren würde es
mich aber schon.
>> Ich ersetzte einfach Python mit Tcl und streich den>> Satz mit der Einrückung. Ersetze ihn aber mit den>> schwachsinnigen Kommentaren in Tcl. Das ist nämlich>> gleich dumm wie die Einrückung in Python.>> Naja, zumindest die Syntax von Tcl ist im Vergleich zu> Python ja schon ziemlich primitiv und unelegant.
Naja, das entbehrt nicht einer gewissen Komik, denn ein
Großteil der verfügbaren Operationen und Operatoren ist
1:1 von C übernommen...
(Diese Ähnlichkeit zu C halte ich übrigens für einen
echten didaktischen Vorteil von Tcl.)
> Sie erinnert mich stark an eine Shell-Sprache,
Gut... die Substitutionsmechanismen sind ungewohnt.
> mit ich ungern größere Softwareprojekte realisieren> würde, auch wenn das prinzipiell natürlich möglich> ist.
Wieso? Wo ist da der Zusammenhang? Ich frage ernsthaft.
Die Zuweisungen in der Form
1
set a $b
sind wegen der Präfixnotation und des notwendigen "$"
erstmal murxig, aber das wird schnell zum Reflex.
Der Hauptnachteil der eckigen Auswertungs-Klammern -- wie
übrigens auch der geschweiften -- ist m.E., dass sie so
beschissen auf der Tastatur zu erreichen sind.
Ansonsten sehe ich in der Syntax nix, was größere Projekte
verhindern würde.
>> Ein Vergleich mit C, C++, Java ist nicht zielführend,>> weil das compilierte Sprachen sind.>> Warum nicht?
Naja, das ist dasselbe, als wollte man eine konventionelle
Dreh- oder Fräsmaschine mit einer CNC-Kiste vergleichen:
CNC kann vieles, was konventionell nicht geht -- aber bei
der konventionellen Maschine sehe ich viel leichter, was
passiert, und kann viel leichter eingreifen. Für das Lernen
und Probieren einfach besser.
> Solange ein Programm tut, was es soll, [...]
Nee -- interessant ist die Phase, in der das Programm noch
NICHT das tut, was es soll -- vielleicht deshalb, weil ich
Teile des Problems oder des Lösungsverfahrens noch nicht
verstanden habe. In dieser Phase erfordern Scriptsprachen
m.E. wesentlich weniger Verrenkungen.
Addendum (fast vergessen):
- es darf jeder soviel einrücken wie er will solange er einrücken tut
und dabei Konsistent bleibt
Letztlich helfen aber "stalinistische" Tools wie pep8 einer
parteidoktrinischen Gleichschaltung was Code-Style angeht, sodass
SW-Engineering & -Metrik Tools auf Quellcodestufe so einfach möglich
sind und gelingen dass gut und gerne auch fremde Libs mit moderatem
Aufwand analysiert werden können, obendrein genausogut auch automatisch
umgearbeitet sprich weiterentwickelt werden können.
Bei Programmiersprachen die länger auf dieser Welt sind wurde das
weniger gemacht resp. wurden damit trotz mehr Zeit weniger Fortschritte
erzielt weil wohl irgendwas im Wege stand; ich mutmasse jetzt mal es
sind die entweder ungünstigen Syntaxdefinitionen oder die allzu
hohen/laxen Freiheitsgrade jener Syntaxen...
Nick M. schrieb:> Genauso wie die Kommentare in meinem geliebten> Tcl Schwachsinn sind. Ich bezeichne das gradraus> als Schwachsinn. Weil da jemand einfach nicht> nachgedacht hat.
Ach Gott... das ist doch Kleinkram.
Viel schlimmer finde ich, dass es für mehrfache
Fallunterscheidungen offenbar mal eine case-Anweisung
gab, die aber zu Gunsten einer C-typischen switch-
Konstruktion abgeschafft wurde. So weit, so gut.
Unabhängig davon gibt es natürlich eine break-Anweisung.
Dumm nur, dass sich "switch" so verhält, wie man es von
"case" in Pascal gewohnt ist (es gibt also keinen
automatischen "fall-through"), so dass ein gewohnheitsmäßig
angehängtes "break" am Ende eines Zweiges unerwartete
Wirkung hat... :)
Sheeva P. schrieb:> aber sie kann mir auch ein interaktives Fenster> öffnen, in das ich zum Beispiel hineinzoomen und bestimmte Bereiche> genauer anschauen kann.
Ja toll. Und ich hab einen interaktiven Editor für harmonische
Nockenwellen mit Flachstößeln in Tkl/Tk geschrieben.
Wo du jeden Parameter angeben kannst und dann dazu die Erhebungskurve,
die Ventilgeschwindigkeit und die Beschleunigung jeweils über °KW bei
gegebener Drehzahl graphisch dargestellt wird.
Der ganze Spaß wird dann als G-Code ausgegeben für die Fräsmaschine mit
einer 4. Achse.
Ist auch langweilig, ich weiß.
Ist auch kein Argument für Tcl, ich weiß.
Gilt aber genauso für Python, ich weiß.
Möglicherweise weißt du nicht, dass man das "Schw*nzvergleich" nennt,
ich weiß es.
Sheeva P. schrieb:> [1] https://wiki.tcl-lang.org/page/Tcl+Equivalents+of+Python+Modules
Hast sicherlich ganz aus Versehen das da in deinem Link übersehen:
A cautionary note - the Tcl column is empty not because the
functionality is unavailable, but because no one finds it worthwhile to
complete the table!
Also note that some of these modules make no sense for Tcl.
> Naja, leider scheint hier niemand ausreichend qualifiziert> (oder motiviert), mal einen SACHLICHEN Vergleich z.B.> zwischen Tcl und python vorzunehmen. Ich bin dafür nicht> geeignet -- ich kenne nur Tcl. Interessieren würde es> mich aber schon.
MEIN ganz persönlicher Abtörner bei Tcl/Tk (das war so ca.'95)
offenbarte sich als ich wiederholt /Boilerplate/scschreiben musste der
Fallunterscheidungen/Fehlerbehandlung bei Entgegennahme von
Funtionsrückgaben abwickeln musste: Liste (mit mehreren Elemente)?/
Einzelelement?/ Kein Element?
Sowas ist mir bei Python (damals so vor 1.5 WIMRE) nie untergekommen:
das abwickeln von "[]"/"[EinzelElem]"/"[Elem1, Elem2, ...]" lässt sich
schön homogen mit "for el in
lst"/Iterator/list-comprehnsion/list-sliceing... hinschreiben ohne dass
Fallunterscheidung nötig ist.
Ok, die Errinnerung an damals ist jetzt bröckelig, ich war "jung" und
hatte kein Tcl-Guru in Reichweite um das gute Handwerk abzugucken.
Vielleicht war(en) es auch nur bestimmte Lib-Funktionen (irgend was mit
Verzeichnisse/Dateien listen) welche blöd implementiert waren... ich
weiss es nicht mehr so genau ausser die Lehre welche ich mir merkte:
"SOWAS will ich nicht mehr anfassen".
Wie Tcl heute ist hab ich mir nicht angeguckt, ev. hat es auch Evolution
genossen...
Programmiersprachentheaterintendant schrieb:> Fallunterscheidungen/Fehlerbehandlung bei Entgegennahme von> Funtionsrückgaben abwickeln musste: Liste (mit mehreren Elemente)?/> Einzelelement?/ Kein Element?
Nick M. schrieb:> Bei mir sind Tabs immer schon 2 LZ. Seit ich programmiere.
Es hindert dich überhaupt keiner daran, das auch bei Python so zu
handhaben. Hab ich damals™, zu Zeiten der hübschen 4:3-Monitore mit
verhältnismäßig geringer Auflösung, genau so gemacht, damit’s im Editor
nicht zu weit nach rechts abgehauen ist, wenn es mal etwas
verschachtelter wurde. Dass es konsistent sein sollte, dürfte sich
eigentlich von selbst verstehen. Zumindest würde ich ansonsten gleiches
Recht für alle fordern, und in anderen Sprachen auch Klammern wild
mischen dürfen:
1
int main () [
2
…
3
}
OT: weil du TCL ins Spiel gebracht hast: ich hab das wegen seiner
Klammerorgien gehasst, wenn ich damit mal zu tun hatte (und zwar noch,
bevor ich Python überhaupt kannte). Ist mir aber nicht in den Sinn
gekommen, es deswegen „Schwachsinn“ zu nennen und zu behaupten, ich
alleine wüsste, wie man es zu machen hätte …
Rolf M. schrieb:> Ich hab ja schon geschrieben, dass ich über ein "das macht man nicht.> Whitespace setzt man so nicht ein, basta!" hinaus nicht viel an> Argumenten finden konnte.
Es gab auch einige "ich mag das einfach nicht"... ;-)
> Du bist da eher die Ausnahme mit dem Argument> des zur Fehlersuche temporär eingefügten Code, und ich habe ja> bestätigt, dass ich das auch als störend empfinde.
Wie müßte ich mir das mit diesem temporär eingefügten Code denn in der
Praxis vorstellen? Vielleicht habt Ihr da ja andere, womöglich bessere
Ideen als ich.
Unterhalb der Blockebene ist mein Code üblicherweise in kleine,
zusammenhängende Einheiten strukturiert. Weil das jetzt sehr abstrakt
klingt, möchte ich ein kurzes Beispiel aus dem Skript geben, mit dem ich
die oben verlinkte Statistik erzeuge. Da ist mir tatsächlich heute ein
kleiner Fehler aufgefallen, in folgendem Code:
DAYS = ['Montag', 'Dienstag', 'Mittwoch', 'Donnerstag',
3
'Freitag', 'Samstag', 'Sonntag']
4
plot_dayofweek.index = DAYS # Fehler hier!
Es folgt noch eine Zeile, aber dies ist der Code, der den mittleren Plot
in der Thread-Statistik erzeugt. Oberhalb und unterhalb des Code
befindet sich jeweils eine Leerzeile, um ihn von dem Code abzusetzen,
der die Plots für Stunden und Datum baut. Nun, jedenfalls warf der
betreffende Code eine Exception und brach die Ausführung in der Zeile "#
Fehler hier!" ab. Also habe ich meinen Code editiert:
Dabei kam heraus -- ich hatte das Skript auf diesen Thread hier
angewendet -- daß dieser Thread erst seit Dienstag läuft, der Dataframe
also nur vier Tage beinhaltet und daher meckert, wenn ich ihm meinen
siebenstelligen Index mit allen Wochentagen zuweisen will. Jetzt sieht
mein Code so aus und funktioniert wieder perfekt:
Da mein Code ansonsten keinerlei print()-Statements enthält, sondern
natürlich das logging-Framework aus Pythons Standardbibliothek benutzt,
wäre der Debug-Code (mit "# Wooot?" gekennzeichnet) auch schnell
wiedergefunden und entfernt, ansonsten hätte ich ihn mit drei Leerzeilen
abgesetzt oder mit Kommentaren gerahmt.
Nebenbei hat mich das an einen anderen Punkt erinnert, der sicherlich
auch zur großen Beliebtheit von Python beiträgt: die einfachen
Möglichkeiten zum Debugging. Angefangen damit, daß ich Code einfach
auskommentieren kann -- sowohl als einzelne Zeile mit dem auch aus
anderen Sprachen bekannten Hashpound, als auch einfach als
Multiline-String mit """ oder ''' an Anfang und Ende.
Außerdem läßt sich so ziemlich jedes Python-Objekt in einen String
wandeln und auf der Kommandozeile oder in eine Logdatei ausgeben. Wenn
das noch nicht reicht, kann ich mit type() den Typ meines Objekts
erfragen, mit dir() alle Symbole im aktuellen Scope ausgeben oder mit
dir(obj) alle Methoden- und Eigenschaftsnamen im Scope des übergebenen
Objekts. Mit vars() kann ich das die lokalen Variablen ausgeben (genau
wie mit locals()), oder mit vars(obj) das interne _dict_ des
übergebenen Objekts.
Eine andere sehr interessante Eigenschaft sind die Docstrings -- und die
manchmal sehr nützliche Möglichkeit, über die Eigenschaft _doc_ direkt
aus dem Code meines Programms heraus auf die eigene Dokumentation oder
die anderer Objekte zuzugreifen.
Für die Docstrings gibt es noch eine andere, durchaus nützliche
Verwendung: die Doctests. Damit kann ich für simple Klassen und
Funktionen ganz einfach eine Art Unittest erstellen: ich lade das Teil
in eine interaktive Python-Shell, lade meine Funktionen und Klassen,
führe sie aus und speichere das in einem Docstring. Dazu ein kleines
Beispiel:
Diese "Unittests" sind zwar sehr einfach, und für umfangreicheren Code
würde ich natürlich ein entsprechendes Framework wie das im
Standardumfang von Python befindliche unittest, oder auch etwas externes
wie PyTest oder Testify nehmen. Jedoch... für einfache Anwendungsfälle
ist doctest schon sehr brauchbar, nicht zuletzt auch, weil der Code in
den Kommentaren gleichzeitig auch beispielhaft dokumentiert, wie die
einzelnen Objekte genau benutzt werden.
>> Hast du das gesucht? ;-)
Ich verstehe zwar dein ";-)" und auch wenn meine Errinnerungen nicht
mehr so präzise sind, bin ich doch zuversichtlich dass ich das gefunden
hatte.
Meine Beschreibung sagt aber dass die Fallunterscheidung nötig war BEVOR
das zur anwendung kommen kann.
Ich versuche zu rekonstruieren: schreib in deinem Codeabschnitt an
Stelle von "$elements" einen Funktionsaufruf hin - geht das dann
immernoch? Egal ob die Funktion eine mehrelementige Liste oder ein
Einzelelement oder NOPE zurückgibt?
Nick M. schrieb:> Oder Revanchist? Jetzt ehrlich!> "Denen werde ich die Hammelbeine schon langziehen! Die werden die> Einrückungen 4 Leerzeichen machen, weil ein Tab immer 4 Leerzeichen> sind. Und damit die das kapieren, dürfen LZ und Tab nicht gemischt> werden. Jawollllll! <harharhar>">> Bei mir sind Tabs immer schon 2 LZ. Seit ich programmiere.
Jetzt ehrlich: Python ist das vollkommen gleichgültig, ob Du für die
Indentation nun ein, zwei, vier oder drölf Leerzeichen benutzt. Es muß
nur konsistent sein. Ich hab früher übrigens auch zwei Leerzeichen
benutzt, bis ich irgendwann zu faul wurde, den Editor umzukonfigurieren
und meine Mitarbeiter und Kollegen damit zu stressen.
Jack V. schrieb:> Zumindest würde ich ansonsten gleiches> Recht für alle fordern, und in anderen Sprachen auch Klammern wild> mischen dürfen:
Huch! Hab ich das gefordert? Dann muss ich mich entschuldigen! Das wäre
ja Schwachsinn[tm].
Jack V. schrieb:> OT: weil du TCL ins Spiel gebracht hast: ich hab das wegen seiner> Klammerorgien gehasst,
OK, ich hab vorher ObjC gelernt, da gewöhnt man sich an eckige Klammern
gaaaanz schnell. Und dass bei jedem Funktionsaufruf der parameter auch
mit Namen genannt werden muss (wie bei Verilog wenn man die Reihenfolge
ändert). Und irgendwie muss man da immer von innen nach aussen lesen,
wobei innen eher rechts steht. Ist halt so, es war meine
Lieblingssprache bis jetzt.
Aber sublime macht aus einem "proc<tab> ein:
proc name {args} \
{
}
Darum liebe ich Orgien. ;-)
Aber zugegeben, mit diesen eckigen und geschweiften Klammern oder die ""
und was die machen oder nicht, das ist nicht ganz so einfach. Aber das
ist halt Syntax die festlegt wann Ausdrücke berechnet werden. Und das
find ich verdammt cool.
Aber eigentlich geht es um Python, nicht dass noch einer vom Glauben
abfällt. ;-)
Egon D. schrieb:> Yalu X. schrieb:>> Nur dass IMHO Python mehr Vorteile und weniger Nachteile>> in sich vereint als andere Programmiersprachen.>> Naja, leider scheint hier niemand ausreichend qualifiziert> (oder motiviert), mal einen SACHLICHEN Vergleich z.B.> zwischen Tcl und python vorzunehmen. Ich bin dafür nicht> geeignet -- ich kenne nur Tcl. Interessieren würde es> mich aber schon.
Vielleicht ließe sich das ja als eine Art "Gemeinschaftsarbeit" in einem
eigenen Thread machen? Immerhin gibt es hier in diesem Thread schon
doppelt so viele Tcl-Freunde, als mir bisher je persönlich begegnet
sind.
> Naja, das entbehrt nicht einer gewissen Komik, denn ein> Großteil der verfügbaren Operationen und Operatoren ist> 1:1 von C übernommen...>> (Diese Ähnlichkeit zu C halte ich übrigens für einen> echten didaktischen Vorteil von Tcl.)
Naja, die Syntax von C als hochentwickelt oder gar eleganz zu
bezeichnen, erscheint mir allerdings ziemlich... mutig.
> Die Zuweisungen in der Form>
1
> set a $b
2
>
> sind wegen der Präfixnotation und des notwendigen "$"> erstmal murxig, aber das wird schnell zum Reflex.
Immerhin wurde meines Wissens auf echte polnische Notation verzichtet --
und, vor allem, auf Klammern!
>> Solange ein Programm tut, was es soll, [...]>> Nee -- interessant ist die Phase, in der das Programm noch> NICHT das tut, was es soll -- vielleicht deshalb, weil ich> Teile des Problems oder des Lösungsverfahrens noch nicht> verstanden habe. In dieser Phase erfordern Scriptsprachen> m.E. wesentlich weniger Verrenkungen.
Vor allem sind sie meistens kompakter, man muß sich bei der Fehlersuche
also durch wesentlich weniger Code fräsen. Und Skriptsprachen bieten,
wenngleich in ziemlich unterschiedlichem Ausmaß, oft viel bessere
Möglichkeiten zur Introspektion.
Jack V. schrieb:> OT: weil du TCL ins Spiel gebracht hast: ich hab das> wegen seiner Klammerorgien gehasst,
Das ist legitim (auch wenn es mir nicht so geht).
> Ist mir aber nicht in den Sinn gekommen, es deswegen> „Schwachsinn“ zu nennen [...]
Kannst Du ja bei Bedarf noch nachholen... :)
> und zu behaupten, ich alleine wüsste, wie man es zu> machen hätte …
Nee, umgekehrt: Es geht nur darum, wie man es garantiert
NICHT machen soll.
Siehe mein Beispiel mit "switch": Tcl ahmt in vielen
Dingen C nach (und das ist auch gut so), gerade was die
Steuerstruktur betrifft. Wie man da auf die Idee kommen
kann, eine Steueranweisung zu schaffen, die GENAUSO
aussieht wie die Entsprechung in C, sich aber ANDERS
verhält -- das wird mir ewig ein Rätsel bleiben. Das ist
doch geradezu eine Einladung für idiotische Irrtümer!
Sheeva P. schrieb:> Jetzt ehrlich: Python ist das vollkommen gleichgültig, ob Du für die> Indentation nun ein, zwei, vier oder drölf Leerzeichen benutzt.
Nur nicht Tabs und LZ mischen, das hab ich schon verstanden.
Ist ja auch einleuchtend, denn so darf jeder das machen was einer
festlegt.
Wobei es jeder so machen kann, wie er mag, solang sich die Anderen daran
halten.
8-/
Nick M. schrieb:> Sheeva P. schrieb:>> aber sie kann mir auch ein interaktives Fenster>> öffnen, in das ich zum Beispiel hineinzoomen und bestimmte Bereiche>> genauer anschauen kann.>> Ja toll. Und ich hab einen interaktiven Editor für harmonische> Nockenwellen mit Flachstößeln in Tkl/Tk geschrieben.
Schick, aber Du hattest ein Beispiel genannt und ich erklärt, daß es in
Python für dieses Beispiel deutlich bessere (und hübschere)
Möglichkeiten gibt, und zwar ohne dazu auf externe Software zugreifen zu
müssen.
> Möglicherweise weißt du nicht, dass man das "Schw*nzvergleich" nennt,> ich weiß es.
Ach... Du kannst es einfach nicht lassen, nein?
> Sheeva P. schrieb:>> [1] https://wiki.tcl-lang.org/page/Tcl+Equivalents+of+Python+Modules>> Hast sicherlich ganz aus Versehen das da in deinem Link übersehen:
Nein. Im Gegenteil hatte ich sogar ausdrücklich dazu geschrieben, daß
diese Liste womöglich unvollständig sein könnte.
>> Hast du das gesucht? ;-)
Ich glaube, er meint das, was in Python als List Comprehension
bezeichnet wird. Die beiden folgenden Codeteile tun (im Prinzip)
dasselbe:
1
result = list()
2
for elem in liste:
3
result.append(machwas(elem))
und
1
result = [machwas(elem) for elem in liste]
Das ist hier nur ein bisschen syntaktisches Zückerchen, inspiriert von
Haskell. Spannender wird die Sache im Zusammenhang mit Tupeln (Datentyp
tuple), quasi einer unveränderlichen Liste, weil die keine
append()-Methode haben (unveränderlich halt), so daß das erste Beispiel
die Ergebnisse von machwas() dann nämlich erst in einer Liste sammeln
und diese dann in ein Tupel umwandeln müßte.
Jack V. schrieb:> OT: weil du TCL ins Spiel gebracht hast: ich hab das wegen seiner> Klammerorgien gehasst, wenn ich damit mal zu tun hatte (und zwar noch,> bevor ich Python überhaupt kannte).
Äh, Du meinst jetzt aber nicht Lisp, oder? ;-)
Sheeva P. schrieb:> Äh, Du meinst jetzt aber nicht Lisp, oder?
Nein. Jede andere Sprache, die ich zu der Zeit kannte, kam mit
erheblich weniger Klammern aus.
Abgesehen davon: „God wrote in Lisp“ – ich selbst habe es nicht
gelernt/genutzt, aber wenn Leute Lieder drüber schreiben, kann es ja
auch nicht ganz verkehrt sein, oder?
"Die Perl-Entwickler haben über zehn Jahre an Perl6 entwickelt, das
jetzt
seit 5 Jahren veröffentlicht ist."
perl6 wird wohl viel eher als eigene, unabhängige Sprache gesehen. Und
zum Teil auch als eine Totgeburt.
Egon D. schrieb:> Siehe mein Beispiel mit "switch": Tcl ahmt in vielen> Dingen C nach
Das ist so wie mit Französisch, Italienisch und Spanisch. Gleicher
Sprachstamm. Wer Französich kann, tut sich mit Italienisch leicht oder
versteht es zumindest ansatzweise. Manche Französischen Wörter spricht
man einfach italienisch aus und das passt dann. So wie Italiener sich
leicht tun wenn die Spanier endlich mal langsam sprechen.
Aber es gibt keinen Anspruch darauf, dass Fränzösich wie Italienisch und
Tcl wie C verhalten muss.
Und dass das alles von Latein abstammt, hab ich als Neusprachler
unterschlagen.
Alle Sprachen sind nur ein Ausdrucksmittel. Das gilt für C und für
Python und für Russisch (Äquivalent zu APL). In der einen Sprache lässt
sich etwas kompakter oder einfacher oder umständlicher oder klangvoller
ausdrücken wie in der Anderen. Das Französisch die Sprache der Liebe ist
ist genauso Quatsch wie dass Deutsche Spaß verstehen und Italiener bei
Deutsch immer nur Karrrtoffel hören. Dafür kullern sich die Italiener
warum die Bayern immer Grüß Gott sagen. Die verstehen nämlich cruscotto,
was Armaturenbrett bedeutet.
So wie halt die Zahlen in Französich ziemlicher Schwachsinn sind. Wer 92
wie "Vier (mal) zwanzig zwölf" ausspricht, kann nicht ganz dicht sein.
Aber Käse können sie!
Sheeva P. schrieb:> Äh... ist der Backslash da wirklich notwendig? 8-O
Ja. :-))
Ich schreib es aber anders, nämlich so wie eigentlich alle Anderen:
{ } {
Dann braucht man den Backslash nicht. Und ja, auch das ist Unsinn.
Aber ich kann es zugeben! Das macht mir mein Leben einfacher.
Nick M. schrieb:> Sheeva P. schrieb:>> Jetzt ehrlich: Python ist das vollkommen gleichgültig, ob Du für die>> Indentation nun ein, zwei, vier oder drölf Leerzeichen benutzt.>> Nur nicht Tabs und LZ mischen, das hab ich schon verstanden.> Ist ja auch einleuchtend, denn so darf jeder das machen was einer> festlegt.> Wobei es jeder so machen kann, wie er mag, solang sich die Anderen daran> halten.> 8-/
Nein, sogar das ist dem Parser vollkommen wumpe -- jedenfalls, solange
es nicht in derselben Datei passiert. Wenn Du Deinen Code also mit einer
Indentierung von zwei Leerzeichen schreibst, kannst Du jederzeit Code
laden, der sich an PEP8 hält, also vier Leerzeichen dafür benutzt. Da
ist Python -- wie in vielen anderen Dingen -- ziemlich frei und setzt
mehr auf Konventionen als auf Zwänge.
Irgendwann ist vielleicht mal der Punkt erreicht wo jemand sagt "He, die
vorhandenen Sprachen sind jetzt langsam mal gut genug, jetzt können wir
uns endlich aus Programmieren konzentrieren statt dauernd vermeintlich
bahnbrechenden, inkompatiblen Neuerungen hinterherzuwarten" :)
...
Wenn man auf konsequent andere Syntax steht: Forth bzw Postscript
(letztere Sprache ist sogar tatsächlich verflixt elegant wenn man sich
Beispiele ansieht die nicht von einem Druckertreiber zusammengestampft
wurden :) )
Sheeva P. schrieb:> Spannender wird die Sache im Zusammenhang mit Tupeln (Datentyp> tuple), quasi einer unveränderlichen Liste, weil die keine> append()-Methode haben (unveränderlich halt),
Konstante gibts nicht in Tcl. Man kann aber ein event (eine Funktion)
drauf setzen wenn eine Variable, egal von wem, geändert wird.
Eine n-Tupel im mathematischen Sinne wäre eine Liste. Daraus könnte man
eine Liste von Listen machen oder flach in eine Liste schreiben. Das
foreach kann dann bei letzteren wieder was schönes machen:
foreach tuple1 tuple2 tuple2 in $listOfFlatTuples {
...
Die andere Schreibweise wäre ein 'lmap' über eine Liste.
Sheeva P. schrieb:> Nein, sogar das ist dem Parser vollkommen wumpe -- jedenfalls, solange> es nicht in derselben Datei passiert.
Also doch nicht wumpe. Ausser "wumpe" bedeutet für dich "zwingend
erforderlich".
Andy D. schrieb:> "Die Perl-Entwickler haben über zehn Jahre an Perl6 entwickelt, das> jetzt> seit 5 Jahren veröffentlicht ist.">> perl6 wird wohl viel eher als eigene, unabhängige Sprache gesehen. Und> zum Teil auch als eine Totgeburt.
Ja, sie haben Perl6 jetzt in Rake umbenannt. Wobei eine der ultimativen
Stärken von Perl das CPAN war, wo es -- ähnlich wie heute in Python --
Bibliotheken für nahezu alles gegeben hat. Keine Ahnung, wie das
weitergehen soll... :-(
Mir tut die heutige Situation von Perl in der Seele weh, schließlich hat
es mich über zehn Jahre begleitet und war mir immer ein guter, treuer
Freund. Heute benutze ich es nurmehr als Filter in der Shell:
1
cat 507607.html | perl -pe 's/Andy D./andi d./g'
an Stellen, wo andere zu sed(1) oder awk(1) greifen... wirklich schade.
Aber gleichzeitig bin ich auch dankbar: Perl hat mich viel über
Skriptsprachen und ihre Ausführungsmodelle, über Perl-Compatible Regular
Expressions, und über krude Objektorientierung (bless...) gelehrt.
Lustige Anekdote: vor vielen Jahren -- als Perl6 gerade im Gespräch und
ich noch nicht zu Python gewechselt war, hat mir ein Lektor des
Rheinwerk-Verlags angeboten, ein Buch über Perl6 zu schreiben... Heute
sind wir vermutlich beide froh, daß ich damals abgelehnt habe. Und zu
den besten Programmierbüchern, die ich je gelesen habe, gehört immer
noch "Objektorientiert Programmieren mit Perl" von Damian Conway.
Nick M. schrieb:> Sheeva P. schrieb:>> Äh... ist der Backslash da wirklich notwendig? 8-O>> Ja. :-))
Oh, interessant.
> Ich schreib es aber anders, nämlich so wie eigentlich alle Anderen:> { } {> Dann braucht man den Backslash nicht. Und ja, auch das ist Unsinn.> Aber ich kann es zugeben! Das macht mir mein Leben einfacher.
Alles gut, aber... äh... dann spielt Whitespace ja auch in Tcl eine
Rolle, oder verstehe ich da gerade etwas falsch?
Wie auch immer: ich halte die Sache mit der Einrückung in Python nicht
für Unsinn, sondern... im Prinzip eher für eine Art Konsolidierung
dessen, was der Interpreter oder Compiuler sieht und dem, was ich sehe.
Auch in C, C++, JavaScript, Perl, PHP, Java, Scala, Kotlin -- und ein
paar anderen Sprachen, die ich glücklich- und erfreulicherweise schon
vergessen habe -- und sogar in LaTeX, CSS, HTML, XML, JSON, SVG, SQL,
und wie das olle Gerümpel auch heißen mag, habe ich immer penibelst auf
eine saubere Einrückung geachtet. Passiert mir ja ohne das schon oft
genug, daß ich beim Lesen von Code in einer von zwei Situationen bin:
entweder denke ich "Alter, was für ein Genie, so gut würde ich auch
programmieren können" oder "Meine Güte, was für ein Scheiß, welcher
Idiot hat das verbrochen". Am Ende stellt sich dann (für meinen
Geschmack zu oft) heraus: ist beides von mir. Zum Glück ist die erste
Situation noch häufiger -- und wenn sie das nicht mehr ist, dann suche
ich mir was Neues. Blumenpflücken soll ja sehr entspannt sein.
Nick M. schrieb:> Egon D. schrieb:>> Siehe mein Beispiel mit "switch": Tcl ahmt in>> vielen Dingen C nach>> Das ist so wie mit Französisch, Italienisch und> Spanisch. Gleicher Sprachstamm.
Fast -- aber nicht ganz dasselbe: Natürliche Sprachen
werden letztlich beim Sprechen durch die Sprechenden
geformt -- formale Sprachen haben einen Schöpfer, und
der kann halt auch mal Fehlentscheidungen treffen :)
> Aber es gibt keinen Anspruch darauf, dass Fränzösich> wie Italienisch und Tcl wie C verhalten muss.
Wer redet von "Anspruch"? Du musst Tcl übrigens mir
gegenüber nicht verteidigen :)
Lange Zeit ist mir die Verwandtschaft zwischen Tcl und C
gar nicht aufgefallen; ich kann (noch) kein C. Als ich
mit Lernen anfing, stellte ich dann freudig erregt fest,
dass ich einen Großteil der Steuerstruktur und einen Teil
der Operatoren von C schon kenne. Nur die Ausnahme mit
"switch" und "break" stach halt ins Auge; das hätte m.E.
nicht sein müssen.
> Alle Sprachen sind nur ein Ausdrucksmittel. Das gilt> für C und für Python und für Russisch (Äquivalent zu> APL). In der einen Sprache lässt sich etwas kompakter> oder einfacher oder umständlicher oder klangvoller> ausdrücken wie in der Anderen.
Ja sicher -- aber (danke für die Vorlage) hier wurde ein
"falscher Freund" geschaffen, der nicht hätte sein müssen.
Mehr habe ich gar nicht gesagt.
Sheeva P. schrieb:> Alles gut, aber... äh... dann spielt Whitespace ja auch in Tcl eine> Rolle, oder verstehe ich da gerade etwas falsch?
Ja, halbwegs schlecht geschauspielert. Es geht um das '\n' das durch das
'\\' aufgehoben wird. Du kannst also beliebig viele LZ oder <tab>
einfügen, was ja auch Whitespaces sind. Was aber nicht bedeutet, dass
ich das sinnvoll finde.
Sheeva P. schrieb:> Wie auch immer: ich halte die Sache mit der Einrückung in Python nicht> für Unsinn, sondern... im Prinzip eher für eine Art Konsolidierung> dessen, was der Interpreter oder Compiuler sieht und dem, was ich sehe.
Deine Hartnäckigkeit ist erschreckend! Wer hat hier jemals abgestritten,
dass sauberes Formatieren einfach zum Handwerkzeug gehört?
Oh, und das muss natürlich ein Monospaced Font sein, sonst klappt das
nicht. Aber das ist ja loooogisch. **Pffff**
Wie viele Compiler // Interpreter // Parser hast du schon geschrieben?
Ich vermute das nähert sich extrem gegen Null.
Sheeva P. schrieb:> und wie das olle Gerümpel auch heißen mag, habe ich immer penibelst auf> eine saubere Einrückung geachtet.
Ah, wenn ich einen Dump einer XML-Nachricht mach, dann ist der
eingerückt. Wenn ich die zum Server schick ist das ein schweinelanger
Einzeiler. Weil sonst das Gejammer losgeht dass so viele unnötige Daten
übertragen werden **heul**. Der Inhalt ist aber identisch. Genauso kann
ich das auch empfangen, unnötige Whitespaces wirden als allererstes beim
Parsen wegeworfen.
OK, ist das jetzt sauber:
Weißt du, wo ich <tab> und wo ich LZ getippt hab? Ist doch egal, sieht
man ja nicht.
Nur weil du es als sauber betrachtes, müssen das nicht Alle so sehen.
Dem C-Compiler sind alle Varianten wurscht. Er überlässt meine
persönlichen Vorstellungen weitestgehend mir.
Versuch endlich mal Darstellung und Inhalt auseinander zu halten. Das
sind zwei Dinger.
Andy D. schrieb:> Irgendwann ist vielleicht mal der Punkt erreicht wo jemand sagt "He, die> vorhandenen Sprachen sind jetzt langsam mal gut genug, jetzt können wir> uns endlich aus Programmieren konzentrieren statt dauernd vermeintlich> bahnbrechenden, inkompatiblen Neuerungen hinterherzuwarten" :)
Naja, im Prinzip ist das ja zumindest bei den Skriptsprachen schon der
Fall. Alle heute weit verbreiteten Sprachen stammen im Wesentlichen aus
derselben Epoche, die allerdings damals noch geprägt war von
Single-Core-CPUs.
Heute ist die Situation allerdings anders, die meisten Prozessoren haben
mehrere Rechenkerne und viele sogar mehrere Threads pro Rechenkern
(Hyperthreading). Das verändert die Bedingungen, für die Skriptsprachen
entwickelt werden.
Python und Ruby zum Beispiel leiden an etwas, das sich "Global
Interpreter Lock" nennt. Das ist wirklich nervig, weil es ein wirkliches
Multithreading effektiv verhindert. CPython hat deswegen ein Modul
namens multiprocessing mit im Prinzip derselben Syntax wie das
multithreading-Modul, was die Sache wieder ein bisschen erträglicher
macht.
Lustigerweise kennen Jython und IronPython, die auf Java und C#
basieren, sowas wie ein GIL nicht. Aber die haben ihre eigene Garbage
Collection -- die zumindest unter Java mit dem ZeroGC etwas erträglicher
geworden ist und vorher gerne unter Memory Leaks und anderen
Nickeligkeiten gelitten hat.
Insofern, kurz gesagt: die Hardware entwickelt sich weiter, und damit
müßten das auch die Programmiersprachen tun. Aber die verbreitetsten
Skriptsprachen sind noch aus einer Zeit der einzelnen Singlecore-CPUs.
Mein damaliger Arbeitgeber Sun hat Java entwickelt, und da wir damals
schon Maschinen mit mehreren Kernen hatten, ist das einer der wenigen
Aspekte, in denen Java wirklich stark ist.
Insofern, um Deine Frage zu beantworten: nein, die heutigen Sprachen
sind noch lange nicht gut genug und werden es auch morgen nicht sein.
Übermorgen vielleicht, ja. Es wird sich zeigen, welche überleben und
welche nicht. Und dann lernen wir halt eine neue Sprache. Na und? Das
tut nur den One-Trick-Ponies weh... und auch die werden dann entweder
Blümchenpflücker oder Rentner.
PS: Bevor ich hier wieder wegen der One-Trick-Ponies angekackt werde...
Es gibt einige Softwareentwickler, die genau eine Sprache können und
sich mit Händen und Füßen dagegen wehren, eine neue zu lernen. Aus
meiner persönlichen Erfahrung liegt das oft daran, daß man mit der
ersten Programmiersprache ja nicht nur die Sprache, sondern auch das
Programmieren erlernen muß. Letzteres ist der wesentlich härtere Teil,
und... für manche Menschen ist das so eine böse Erfahrung, daß sie sich
die nicht noch einmal antun wollen. :-(
Nick M. schrieb:> Sheeva P. schrieb:>> Spannender wird die Sache im Zusammenhang mit Tupeln (Datentyp>> tuple), quasi einer unveränderlichen Liste, weil die keine>> append()-Methode haben (unveränderlich halt),>> Konstante gibts nicht in Tcl. Man kann aber ein event (eine Funktion)> drauf setzen wenn eine Variable, egal von wem, geändert wird.
Ja, nein, vielleicht... Python hat zwei Datentypen für Listen, nämlich
die Liste (list) und das Tupel (tuple). Ein Tupel als solches ist
unveränderlich, aber ich kann einer Variablen, die ein Tupel hält,
selbstverständlich immer ein anderes Tupel zuweisen. Denn Python ist
dynamisch typisiert, bindet die Datentypen also an den Wert einer
Variablen statt wie C, , C++ und Java, ans Symbol.
> Eine n-Tupel im mathematischen Sinne wäre eine Liste. Daraus könnte man> eine Liste von Listen machen oder flach in eine Liste schreiben. Das> foreach kann dann bei letzteren wieder was schönes machen:>> foreach tuple1 tuple2 tuple2 in $listOfFlatTuples {
Mehrfachzuweisung, nice. Python, anyone? Aber (unter anderem) deswegen
gibt es in Python einen spezialisierten Iterable-Typ wie das Tupel.
Damit Du sicher sein kannst, daß Dein Listelement nur genau drei Werte
enthält... ;-)
Egon D. schrieb:> Habe ich das jetzt richtig verstanden:
[...]
> 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?
Und:
Egon D. schrieb:> ich kann (noch) kein C
Du sagst selbst, Du kennst weder Python noch C.
Ich stelle es mir sehr schwierig vor, mit so wenig Wissen und ohne
Erfahrung an dieser Diskussion hier aktiv teilzunehmen.
Nick M. schrieb:> Oh, und das muss natürlich ein Monospaced Font sein, sonst klappt das> nicht.
Nein, das ist falsch, da auch in einer proportionalen Schrift das
Leerzeichen eine fixe Breite besitzt.
Irgendwer schrieb:> Egon D. schrieb:>> ich kann (noch) kein C>> Du sagst selbst, Du kennst weder Python noch C.>> Ich stelle es mir sehr schwierig vor, mit so wenig> Wissen und ohne Erfahrung an dieser Diskussion hier> aktiv teilzunehmen.
Echt jetzt?!
Falls mir mal SEHR langweilig sein sollte und ich Lust
habe, mich provozieren zu lassen, sage ich bescheid.
Im Moment ist das noch nicht der Fall.
Nick M. schrieb:> Egon D. schrieb:>> Ja sicher -- aber (danke für die Vorlage) hier wurde ein>> "falscher Freund" geschaffen, der nicht hätte sein müssen.>> Meinst du den Russen?
Nein. Ich meine immer noch die switch-Anweisung in Tcl bzw.
in C.
Und -- ganz nebenbei: Ich finde es ein wenig enttäuschend,
dass Du nicht entweder zugeben kannst, dass ich Recht habe,
oder mir nachweist, dass ich mit meinen Aussagen Unrecht
habe. Das ist m.E. unter Deinem Niveau -- aber das ist
letztlich Deine Sache.
> Kennst du APL?
Nein -- aber eins glaube ich ohne jeden Nachweis: Schlimmer
geht es immer.
Nick M. schrieb:> Sheeva P. schrieb:>> Alles gut, aber... äh... dann spielt Whitespace ja auch in Tcl eine>> Rolle, oder verstehe ich da gerade etwas falsch?>> Ja, halbwegs schlecht geschauspielert. Es geht um das '\n' das durch das> '\\' aufgehoben wird.
Du maskierst ein Newline. Wow.
> Sheeva P. schrieb:>> Wie auch immer: ich halte die Sache mit der Einrückung in Python nicht>> für Unsinn, sondern... im Prinzip eher für eine Art Konsolidierung>> dessen, was der Interpreter oder Compiuler sieht und dem, was ich sehe.>> Deine Hartnäckigkeit ist erschreckend! Wer hat hier jemals abgestritten,> dass sauberes Formatieren einfach zum Handwerkzeug gehört?
Du bezeichnest eine von Pythons Eigenschaften als "Schwachsinn", weil es
nunmal diese Eigenschaft hat. Ich hingegen habe praktische Erfahrung mit
Python und weiß deswegen, daß das kein "Schwachsinn" ist. Wer von uns
beiden kann jetzt wohl die qualifiziertere Aussage darüber treffen?
> Wie viele Compiler // Interpreter // Parser hast du schon geschrieben?
Keine Ahnung. Zehn, Zwanzig, Tausend? Wayne?
> Ich vermute das nähert sich extrem gegen Null.
Ach, vermute Du mal. ;-)
> Weißt du, wo ich <tab> und wo ich LZ getippt hab? Ist doch egal, sieht> man ja nicht.
Ja... und? Was ist Dein Punkt?
> Nur weil du es als sauber betrachtes, müssen das nicht Alle so sehen.
Schon wieder so eine Unterstellung. Kannst Du das wirklich nicht besser?
Ja, ich halte das für eine gute Idee, weil es die Sicht des
Übersetzers mit der des Entwicklers zusammenbringt. Das darfst Du aber
gern anders sehen.
Irgendwer schrieb:> Nein, das ist falsch, da auch in einer proportionalen Schrift das> Leerzeichen eine fixe Breite besitzt.
Es würde mich nicht wundern, wenn hier jemand seinen Code im Blocksatz
formatiert.
Jemand schrieb:> Irgendwer schrieb:>> Nein, das ist falsch, da auch in einer proportionalen>> Schrift das Leerzeichen eine fixe Breite besitzt.>> Es würde mich nicht wundern, wenn hier jemand seinen> Code im Blocksatz formatiert.
Dann aber auch als Knittelvers.
Egon D. schrieb:> Nein. Ich meine immer noch die switch-Anweisung in Tcl bzw.> in C.
Ah, OK.
> Und -- ganz nebenbei: Ich finde es ein wenig enttäuschend,> dass Du nicht entweder zugeben kannst, dass ich Recht habe,> oder mir nachweist, dass ich mit meinen Aussagen Unrecht> habe.
Wegen dem switch / case?
Ja, hab ich doch schon beantwortet. Nur weil deinem Empfinden nach
Sprachen ähnlich sind, kannst du doch nicht fordern, dass die das switch
und case gleich verwenden.
Ist halt so. Soll ich mich darüber aufregen? Wenn ich mich über den
Unterschied aufregen würde, werde die Konsequenz, dass es nur eine
einzige Programmiersprache gäbe. Da wäre ich dagegen.
Und zu deiner Beruhigung:
Du hast weder Recht noch Unrecht. Dir gefällt es nicht. Und das ist
absolut OK.
Ich find auch nicht, dass C ähnlich zu Tkl ist. Da ist Python deutlich
näher dran.
Jemand schrieb:>> Nein, das ist falsch, da auch in einer proportionalen Schrift das>> Leerzeichen eine fixe Breite besitzt.>> Es würde mich nicht wundern, wenn hier jemand seinen Code im Blocksatz> formatiert.
D. Knuth, Literate Programming
Muss man gelesen haben.
Sheeva P. schrieb:> also nur vier Tage beinhaltet und daher meckert, wenn ich ihm meinen> siebenstelligen Index mit allen Wochentagen zuweisen will. Jetzt sieht> mein Code so aus und funktioniert wieder perfekt:> plot_dayofweek = df.groupby(df.time.dt.dayofweek).time.count()> DAYS = ['Montag', 'Dienstag', 'Mittwoch', 'Donnerstag',> 'Freitag', 'Samstag', 'Sonntag']> days = list()> for i in plot_dayofweek.index: days.append(DAYS[i])> plot_dayofweek.index = days> plot_dayofweek = plot_dayofweek.plot_bokeh(> kind='bar', show_figure=False, xlabel='Wochentag',> ylabel='Anzahl Beiträge', legend=None, colormap=['orange'])>> Da mein Code ansonsten keinerlei print()-Statements enthält, sondern
Urgs, das wäre nicht mein Python Stil :-)
1
...
2
DAYS = 'Montag Dienstag Mittwoch Donnerstag Freitag Samstag Sonntag'.split()
3
plot_dayofweek.index = tuple( DAYS[i] for i in plot_dayofweek.index )
Sheeva P. schrieb:> 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.
Dann lies nochmal objektiv, denn diese Aussage ist definitiv falsch.
Ich nutze Python weil es, nach Abwägen aller Vor- und Nachteile, für
mich insgesamt das beste Gesamtpaket mitbringt.
Das Whitespace-"Feature" zähle ich aber als großen Nachteil.
Klar, ein Problem stellt es jetzt nicht dar.
Es nervt einfach nur.
@All from this thread,
ich lass mal auch was vom Stapel ;-)
Nachdem ich mit Python3 erst vor zwei Jahren angefangen habe,
davor war Perl5 und bash mein Skripting Favorit bin ich nun
aber von Python3 zumindest recht angetan.
Die Problematik und die Diskussion über die Tab/Space Einrückungen
sehe ich entspannt und lasse den Anderen den Diskussionsraum
für Ihre Pros und Kontras.
Was mich an Python begeistert ist die Möglichkeit Code erst einfach
zu gestalten, damit es erst einfach läuft und dann in die Tiefe
zu gehen um es falls nötig zu beschleunigen.
Beispiel der Mittelwert-Bildung, siehe Anhang, und der daraus
resultierenden Laufzeit-Optimierung mit den Möglichkeiten die
Python so bietet. Und ich bin bei weitem kein Experte darin.
Da geht sicherlich noch mehr.
mw@linux-kwm1:~/Programming/Python/bsp
>./random_average_python.py
17.96653366999999
mw@linux-kwm1:~/Programming/Python/bsp
>./random_average_numba.py
2.573679684999661
mw@linux-kwm1:~/Programming/Python/bsp
>./random_average_numba_parallel.py
0.793028295998738
Auch die Visualisierung mit matplotlib und pandas ist mir
sehr ans Herz gewachsen und bestimmt auch vielen anderen.
Deshalb habe ich meine Beispiele auch gleich angehängt, damit
auch andere damit spielen können.
Auf jeden Fall hilft mir Python im Arbeitsaltag sehr und hat
in den vergangenen Monaten viel Mühe und Zeit bei Routine-
Tätigkeiten eingespart.
Jetzt beschäftige ich mich mit OpenCV und dann mit NN um in
Richtung MI mein Wissen zu erweitern.
Übrigens geb es gerade diese Woche im Handel vom Heise-Verlag
das iX-Developer Magazin (Winter20/21) zum Thema MI und dreimal
könnt Ihr raten in welcher Prog.-Sprache alle Beispiele verfasst
sind.
Markus
Le X. schrieb:> Ich nutze Python weil es, nach Abwägen aller Vor- und Nachteile, für> mich insgesamt das beste Gesamtpaket mitbringt.> Das Whitespace-"Feature" zähle ich aber als großen Nachteil.> Klar, ein Problem stellt es jetzt nicht dar.> Es nervt einfach nur.
Oh, okay, Deine bisherigen Aussagen dazu hatte ich als weniger hart
eingeschätzt.
Markus W. schrieb:> Nachdem ich mit Python3 erst vor zwei Jahren angefangen habe,> davor war Perl5 und bash mein Skripting Favorit bin ich nun> aber von Python3 zumindest recht angetan.> [...]> Da geht sicherlich noch mehr.
Hast Du es mal mit Pypy ausprobiert?
> Auch die Visualisierung mit matplotlib und pandas ist mir> sehr ans Herz gewachsen und bestimmt auch vielen anderen.
+1
> Jetzt beschäftige ich mich mit OpenCV und dann mit NN um in> Richtung MI mein Wissen zu erweitern.
Spannend... ich hacke gerade an einer Bewegungserkennung mit OpenCV auf
einem RasPi4. Vor dem Hintergrund, daß ein Intel Nuc i3 mit Zoneminder
und Motion dabei schon arg ins Schwitzen geraten ist, finde ich es sehr
faszinierend, wie performant die ganze Geschichte mit OpenCV läuft.
Dabei hat der kleine RasPi4 gerade einmal 125 BogoMIPS und der NUC
immerhin 4190. Viel Spaß und Erfolg!
Sheeva P. schrieb:> Dabei hat der kleine RasPi4 gerade einmal 125 BogoMIPS und der NUC> immerhin 4190. Viel Spaß und Erfolg!
Die BogoMIPS sind kein geeignetes Maß für die Verarbeitungsleistung
eines Rechners, deswegen der Präfix Bogo (bogus = unecht, falsch). Der
Wert dient lediglich der Kalibrierung von Busy-Loops für kurze Delays im
Linux-Kernel.
Speziell bei ARMs hat der Wert praktisch überhaupt nichts mehr mit der
Rechenleistung zu tun:
https://en.wikipedia.org/wiki/BogoMips#Timer-based_delays
Dein Raspi hat jedenfalls deutlich mehr als 125/4190 der Rechenleistung
deines NUC.
Yalu X. schrieb:> Dein Raspi hat jedenfalls deutlich mehr als 125/4190 der Rechenleistung> deines NUC.
Klar, aber daß so ein winziger RasPi4 mit OpenCV schneller ist als ein
i3-5010U mit Zoneminder (oder noch schlimmer: Motion), finde ich
trotzdem enorm beeindruckend. Übrigens habe ich mich vertan: der RasPi 3
B+ war der mit den 125 BogoMIPS, mein RasPi4 kommt auf 270. ;-)
Nick M. schrieb:>> Und -- ganz nebenbei: Ich finde es ein wenig enttäuschend,>> dass Du nicht entweder zugeben kannst, dass ich Recht habe,>> oder mir nachweist, dass ich mit meinen Aussagen Unrecht>> habe.>> Wegen dem switch / case?> Ja, hab ich doch schon beantwortet. Nur weil deinem> Empfinden nach Sprachen ähnlich sind, kannst du doch> nicht fordern, dass die das switch und case gleich> verwenden.>> [...]>> Ich find auch nicht, dass C ähnlich zu Tkl ist. [...]
Nun, ich gestehe, dass ich die Differenz zwischen uns
nicht ausgerechnet in DIESEM Punkt vermutet hätte. Aber
gut; ich nehme es zur Kenntnis.
Sheeva P. schrieb:> 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.
Ich bin gerade beim "Python-Stöbern" über diesen Thread gestolpert und
wollte nur am Rande etwas korrigieren:
Also Perl5 und Perl6 haben sich getrennt. Perl6 heißt jetzt Raku und ist
eine eigenständige Sprache. Perl7 (Die 6 hat man jetzt aus gutem Grund
übersprungen.) wurde als Nachfolger von Perl5 angekündigt und wird
abwärtskompatibel sein.
https://de.wikipedia.org/wiki/Raku_(Programmiersprache)https://www.perl.com/article/announcing-perl-7/?ref=alian.info
Gruß Jay
Thread beobachten
Seitenaufteilung abschalten