Hallo, hatte nicht jemand das Ende von C/C++ vorhergesagt bzw. vorhersagen wollen? Irgendwie gehts der Sprache zusammen mit Python prächtig. https://www.heise.de/news/Tiobe-C-ist-Programmiersprache-des-Jahres-2022-7456000.html
Also mal ehrlich, ich finde es erstaunlich, wie es Python auf Platz 1 schaffen konnte. OK, liegt vllt. dran, wie TIOBE auswertet. Allerdings glaube ich kaum, dass mehr Code in Python als in C/C++ und Java geschrieben wird, vor allem, wenn man bedenkt, dass wohl niemand größere Programme in Python erstellen will. Alles IMHO! Gruß Marcus
Naja, YouTube und Reddit laufen zB auf Python, das würde ich jeweils schon als größere Code-Basis werten. Aber Ja, in C++ und Java dürften mehr sloc geschrieben sein - aber wie gesagt, liegt das vermutlich auch daran, wie TIOBE seine Daten erhebt.
Beitrag #7313627 wurde vom Autor gelöscht.
Die Datenerhebnung von TIOBE ist ja sehr umstritten. Andere wie PYPL sind m.E. auch nicht weniger fragwürdig: https://pypl.github.io/PYPL.html?country=DE
> Blasphemie oder Realität?
Die Sache ist letztlich so, jeder hat Dutzende von Geraete zu hause auf
denen ein in C geschriebenes Programm laeuft. Von der elektrischen
Zahnbuerste bis zum blinkenden Weihnachtsbaum.
Python ist eher etwas was zu hilfzwecken genutzt wird. Also z.b fuer
Produktionstools. Und da wird halt auch noch viel in Labview, VEE oder
sogar Basic programmiert.
Geraete die mit Python programmiert sind lassen sich nicht verkaufen
weil sie entweder teurer sind, langsamer oder eine geringere
Akkulaufzeit haben.
Olaf
Wenn man alle Sprachen und damit alle Programmiere in einen Topf wirft kann ja nur stinkender Brei draus werden. Als Student/Lernender mag es ja eine Orientierung geben, welche Sprache man sich als nächstes 'drauf schafft', aber als Anwender (Büroinformatiker oder Datenanalyst oder Haufrau oder Elektroingenieur oder Bauingenieur oderscriptkiddie oder ...) nimmt man halt grad das was man braucht/kann. Manche programmiert in C, eine andere in Basic, vielleicht HTLM/CSS, oder VHDL oder Erlang ... alles im TIOBE - Topf. Auch über die Intelligenz des Jeweiligen sagt es wenig, wenn er grad in C "rumrotzt" oder in ADA hochsichere Satelliten-software 'komponiert'.
Veit D. schrieb: > hatte nicht jemand das Ende von C/C++ vorhergesagt bzw. vorhersagen > wollen? Solche Aussagen hab ich auch vor 20 Jahren schon gehört. Die haben sich nicht bewahrheitet, also gebe ich auch heute nicht viel darauf. Was kommt, wird die Zeit zeigen. Olaf schrieb: >> Blasphemie oder Realität? > > Die Sache ist letztlich so, jeder hat Dutzende von Geraete zu hause auf > denen ein in C geschriebenes Programm laeuft. > Von der elektrischen Zahnbuerste bis zum blinkenden Weihnachtsbaum. Ich würde vermuten, dass es kaum Geräte gibt, auf denen kein C- oder C++-Code läuft. Letztendlich sind Python-Interpreter und Java-Laufzeitumgebung auch darin programmiert, genauso wie der weit überwiegende Teil der Betriebssystem-Kerne und Treiber. Und bei µC-Anwendungen kommt man auch kaum darum herum. > Python ist eher etwas was zu hilfzwecken genutzt wird. Also z.b fuer > Produktionstools. Und da wird halt auch noch viel in Labview, VEE oder > sogar Basic programmiert. Python ist im Bereich Machine Learning sehr stark präsent.
:
Bearbeitet durch User
Veit D. schrieb: > hatte nicht jemand das Ende von C/C++ vorhergesagt bzw. vorhersagen > wollen? Es gibt immer jemanden, der das Ende von irgendwas vorhersagt. Aber ich schätze mal, dass so starke und verbreitete Sprachen wie C/C++ oder Python nicht mehr verschwinden werden, solange nichts wirklich fundamental Besseres erfunden wird. Aber wer weiß, vielleicht programmiert in Zukunft niemand mehr sondern fragt chatGPT und das sucht sich eine Sprache aus.
> Es gibt immer jemanden, der das Ende von irgendwas vorhersagt. Aber ich > schätze mal, dass so starke und verbreitete Sprachen wie C/C++ oder > Python nicht mehr verschwinden werden, Cobol ist auch noch nicht verschwunden. Nur etwas in den Hintergrund gerückt.
DenkenMachtSpaß schrieb: > dass wohl niemand größere Programme in Python erstellen will. Alles, was man in Python erstellt, ist gross.
Selbst eine simple Türklingel braucht heutzutage eine KI. KI Engines schreibt man in C++ und die Anwendungslogik in Python. Kein Wunder, das diese beiden Sprachen die Liste anführen.
Gustl Germanium schrieb: > eine andere in Basic, Wo gibt es noch Basic? Das gab es in den 80ern auf dem C64, aber mit QBasic unter DOS war dann schluss. Beides, wír spielen Country und Western schrieb: > Engines schreibt man in C++ Alternativ zu C++ gibt es noch Oberon. Beides, wír spielen Country und Western schrieb: > die Anwendungslogik in Python Man kann nicht nur Anwendungslogiken in Python erstellen, sondern sogar ganze Programme mit Menüs. Man kann verschiedene Bibliotheken einbinden wie Numpy oder matplotlib und kann damit sehr effizient Grafiken erstellen.
:
Wiederhergestellt durch Moderator
> Man kann verschiedene Bibliotheken einbinden
Ja, bin der Meinung, genau hier liegt der Erfolg von C++ und Python.
Die Leute, die Qt oder Numpy schreiben, verstehen alle C++ Features von
der Bitfummelei bis zum Template Metaprogramming. Wissen, welchen Ansatz
sie für effiziente Bibliotheken brauchen.
Ein Anwendungsprogrammierer kann dann Try&Error Python Code zusammen
kloppen und bekommt trotzdem ein effizientes, wartbares Programm.
Hi Leute, bei mir gab es ein auf und ab bei der Sympathie zu Python. Inzwischen bin ich der Meinung (nachdem ich mich intensiver auf Python eingelassen habe), dass Python von der Konstruktion her eine "Bastelsprache" ist. Ich möchte damit die Leistungen des Entwicklers in keinster Weise schmälern. Ich bewundere die Leute, die solche großen und weit reichenden Entwicklungen anstoßen. Allerdings ist die Sprache oft nicht "streight forward", denn es gibt z.B. bei der Parameterübergabe mehrere Möglichkeiten, z.B. benannte und unbenannte Parameterübergabe. Die tragen erstens nicht zum Verständnis bei und ermöglichen durch vermischen beliebig komplexe Parameterlisten, die nicht gerade einfach zu durchschauen sind. So gibt es IMHO einige weitere undurchdachte oder fehlende(!) Konzepte, die zumindest bei mir immer ein ungutes trial & error Gefühl auslösen oder das Gefühl, den Algorithmus nicht angemessen und "idiotensicher" in der Sprache implementieren zu können. Aber das ist natürlich auch ein sehr subjektiver Eindruck. Ich bin mit C groß geworden. Im Studium war dann Pascal und Occaml angesagt. Ich konnte mich bis heute mit beiden Sprachen nicht recht anfreunden, obwohl ich dabei immer versuche, die Sache wohlwollend und positiv zu betrachten. Obwohl, ich arbeite u.a. im Automatisierungsbereich (Siemens S7). Da ist die STL (Pascal sehr ähnlich) eine Wohltat gegenüber den bisher meist verwendeten Sprache AWL. Oh, sorry, für den langen Post. Aber jetzt hab ich ihn schon geschrieben, dann schick ich ihn auch ab. :-) Gruß Marcus
Olaf schrieb: > Geraete die mit Python programmiert sind lassen sich nicht verkaufen > weil sie entweder teurer sind, langsamer oder eine geringere > Akkulaufzeit haben. Wieder so eine idiotische Allgemeinaussage. Es gibt absolut professionelle Geräte auf denen zB. eine Python GUI läuft oÄ. Ja, für ein ultra low power Embeddedprodukt in Stückzahlen >10k wird man eher kein Python einsetzen. In Forschungshardware, Messgeräten, Produktionstestern etc. die auf einem ARM mit OS laufen, schon.
> Wieder so eine idiotische Allgemeinaussage. Tut sie weh? :) > Ja, für ein ultra low power Embeddedprodukt in Stückzahlen >10k wird man > eher kein Python einsetzen. In Forschungshardware, Messgeräten, > Produktionstestern etc. die auf einem ARM mit OS laufen, schon. Das ist es was ich oben gesagt habe. Es gibt Nischen wo Python verwendet wird, da wo es nicht so drauf ankommt. Wo es egal ist was man schnell zusammenhackt und wie holprig das laeuft, wieviel Strom es verbraucht oder ob der Controller eine Nummer fetter als noetig sein muss. Sobald du aber Geraete in Stueckzahlen verkaufst aendert sich das. Lauf doch mal durch deine Bude und waehle wahllos zehn Geraete aus. Ist da eines wo Python drauf laeuft? Wohl kaum. TV? Linux=C, Router? Linux. NAS? Linux. Toaster? C, FB? C. Sag mir irgendein Geraet was ich im naechsten Mediamarkt kaufen kann wo Python drauf laeuft. Python ist so eine Art intelektuelles Spielzeug fuer Leute die nicht richtig programmieren koennen. Die koennen durchaus andere Faehigkeiten haben! Aber nichts was spaeter einem Kunden verkauft wird. Olaf
Naja, es gibt Millionen Smart-Phones und -TVs, Router… Das ist aber nicht der Nabel der Welt. Python ist doch mit einer anderen Intention entstanden. Der Vorteil, dass Geschwindigkeit über schnelle Bibliotheken (C, C++) erzielt werden kann, zusammen mit der hohen Geschwindigkeit bei der Entwicklung und die Anwendung im (umsatzstarken) riesigen Bereich „Cloud Computing“ sorgen für diese Situation. Sorry, das muss jetzt sein: Mit platten (nicht Kontext bezogenen) Sprüchen publizieren einige Foristen, dass sie den Unterschied von „persönliche Sicht“, „akademischen Selbstanspruch“ sowie „Bedarf und Ökonomie“ nicht auseinanderhalten oder trennen können.
DenkenMachtSpaß schrieb: > ich finde es erstaunlich, wie es Python auf Platz 1 schaffen konnte. Ich nicht. Das ist eine großartige Sprache: stabil, performant, von Haus aus sehr leistungsfähig und mit externen Libraries noch leistungsfähiger. > OK, liegt vllt. dran, wie TIOBE auswertet. Das sicherlich auch, aber andere Programmiersprachenindices wie Red Monk und PYPL nutzen andere Auswertungen und kommen dennoch zu sehr ähnlichen Ergebnissen. > Allerdings glaube ich kaum, dass > mehr Code in Python als in C/C++ und Java geschrieben wird, vor allem, > wenn man bedenkt, dass wohl niemand größere Programme in Python > erstellen will. Da liegst Du vermutlich ein wenig daneben, wenn man sich einmal ansieht, wieviele Python-Programme alleine die englischsprachige Wikipedia hier [1] in ihrer unvollständigen Liste aufzählt. Da sind auch eine ganze Reihe von ziemlich großen Programmen dabei. Mir persönlich wäre auch ein sachlicher Grund bekannt, warum jemand keine größeren Programme in Python entwickeln wollen würde, zumal ich auch selbst schon an einigen nicht ganz kleinen Projekten in Python mitentwickelt habe. [1] https://en.wikipedia.org/wiki/List_of_Python_software
löppt schrieb: > Aber Ja, in C++ und Java dürften mehr sloc geschrieben sein Das liegt womöglich auch daran, daß man in Java und C++ deutlich mehr Codezeilen braucht, um dasselbe zu erreichen wie in Python.
Wilhelm M. schrieb: > Die Datenerhebnung von TIOBE ist ja sehr umstritten. > > Andere wie PYPL sind m.E. auch nicht weniger fragwürdig: > > https://pypl.github.io/PYPL.html?country=DE Das stimmt, aber trotz der anderen Art der Datenerhebung und -Auswertung kommt ja auch PYPL zu einem sehr ähnlichen Ergebnis wie TIOBE, da ist also möglicherweise durchaus etwas dran. Wer das Ganze allerdings zusätzlich noch einmal aus einer etwas anderen Perspektive betrachten möchte, dem seien die Umfragen von StackOverflow wärmstens ans Herz gelegt. Spoiler: auch die Umfragen der letzten Jahre kommen zu ähnlichen Ergebnissen wie die Indizes. Man selbst muß Python natürlich nicht mögen, aber man kommt ja trotzdem nicht an der simplen Realität vorbei, daß viele Leute es zu benutzen und anscheinend auch zu mögen scheinen. Und wer Python ein wenig kennt dürfte auch wissen, warum das so ist.
Assembler unter den Top-Ten? Das ist dann aber schon merkwürdig (im Sinne des Wortes). Das Visual Basic soweit oben ist, verwundert ein wenig. Edmund Weitz setzt u.a. Python für seine "mathematischen" YT-Videos oder vielleicht auch für Vorträge: ChatGPT und die Mathematik https://www.youtube.com/watch?v=medmEMktMlQ (31:47)
olaf schrieb: >> Wieder so eine idiotische Allgemeinaussage. > > Tut sie weh? :) Ja, weil sie so idiotisch ist. Das Fremdschämen ist mir peinlich. > Python ist so eine Art intelektuelles Spielzeug > fuer Leute die nicht richtig programmieren koennen. Genauso wie diese.
Karl Käfer schrieb: > Mir persönlich wäre auch ein > sachlicher Grund bekannt, warum jemand keine größeren Programme in > Python entwickeln wollen würde, zumal ich auch selbst schon an einigen > nicht ganz kleinen Projekten in Python mitentwickelt habe. Meine subjektive Meinung: Mir sind Sprachen mit dynamischer Typisierung immer ein wenig suspekt. Deshalb finde ich auch JavaScript nicht sooo sympatisch. Außerdem gibt es in Python einfach, ich nenne es mal so, "Unregelmäßigkeiten". Im Prinzip sieht Python so aus, als handele es sich um eine "schlanke" Sprache bzw. Sprachumgebung. Bei näherem Hinschauen sehe ich jedoch einige Unstimmigkeiten. Ich bin zwar Akademiker, allerdings tue ich mich mit der Komplexität von Python etwas schwer. evtl. bin ich da stellenweise intellektuell etwas überfordert. Oder mir fehlt einfach noch die Routine. Zumindest fand ich nach anfänglicher Abneigung nach den ersten Schritten Python so interessant, dass ich mir ein kleines Buch zu Gemüte geführt habe. Und beim Lesen sind mir dann doch einige Dinge aufgefallen, die meine Euphorie wieder gedämpft haben. Mir fallen jetzt keine konkreten Dinge ein, aber insgesamt wirken die Konzepte von Python an einigen Stellen unausgereift oder doppelt gemoppelt. Wenn es Dich interessiert, Nehme ich das Buch zur Hand und schau mal, was mich gestört hat. Ach ja: beim Buch handelt es sich um "Python der Grundkurs" von Michael Kofler. Zur Klarstellung: ich werde sicher weiterhin auch in Python programmieren, aber Python wird wahrscheinlich nicht meine Lieblingssprache. Das sind schon C(++) und Java ;-) Ups wieder ein wenig viel geschrieben. Aber zumindest wir beide schlagen uns ja immerhin (noch ;-) nicht die Köpfe ein... :-) :-) Viele Grüße Marcus
DenkenMachtSpaß schrieb: > dass wohl niemand größere Programme in Python > erstellen will. Warum will das keiner?
Wellenleser schrieb: >> dass wohl niemand größere Programme in Python erstellen will. > Warum will das keiner? Mich hat die praktische Erfahrung mit Odoo abgeschreckt. Die Performance des Systems war enttäuschend.
Stefan F. schrieb: > Wellenleser schrieb: >>> dass wohl niemand größere Programme in Python erstellen will. >> Warum will das keiner? > > Mich hat die praktische Erfahrung mit Odoo abgeschreckt. Die Performance > des Systems war enttäuschend. Microsoft Dynamics oder SAP läuft auch enttäuschend langsam, wenn die Konfiguratio nicht passt. Und mit Konfiguration meine ich nicht nur den Server/Kabel/RAM/Speicher…, eben auch die Konfiguration zur gegenseitigen Anbindung (Frotend, Middle Tier, SQL, …). Also ich habe ein paar extrem anspruchsvolle Analysetools für Produktionsdaten erlebt, da kamen die gängigen BI Lösungen nicht mit. Vor allem das schnelle ändern/anpassen war der Hammer.
Olaf schrieb: > Und da wird halt auch noch viel in Basic programmiert. Wurde die Textverarbeitung "Word" nicht früher auch mit Basic geschrieben?
DenkenMachtSpaß schrieb: > Karl Käfer schrieb: >> Mir persönlich wäre auch ein >> sachlicher Grund bekannt, warum jemand keine größeren Programme in >> Python entwickeln wollen würde, zumal ich auch selbst schon an einigen >> nicht ganz kleinen Projekten in Python mitentwickelt habe. > > Meine subjektive Meinung: Mir sind Sprachen mit dynamischer Typisierung > immer ein wenig suspekt. Das höre ich sehr häufig von Entwicklern, die von statisch typisierten Sprachen kommen, und als ich damals von C/C++ zu Perl kam, hat mich das anfangs auch abgeschreckt. Aber in meiner Zeit mit Perl habe ich gelernt, daß das gar kein so großes Thema war wie gedacht. Dabei hat Perl nichtmal die wertgebundenen Typen wie Python -- "1" + 1 wirft in Python natürlich eine Exception, während Perl einfach 2 zurückgibt -- und auch bei der Introspektion ist Perl nicht so stark wie Python. Sowas wie Deskriptoren, mit denen man Eigenschaften viel stärker beschränken kann als mit einer statischen Typprüfung zur Compilezeit, kennt Perl ebenfalls nicht. Dennoch kann man auch in Perl große und sehr große Programme schreiben, trotz der etwas... hüstel speziellen Objektorientierung und anderer Fallstricke. Aber in Perl muß ich sehr diszipliniert (und erfahren) sein, um les- und wartbaren Code zu schreiben, während es in Python genau andersherum ist: dabei müßte ich mir Mühe geben, wenn ich unlesbar schreiben wollte. Auch wenn es sich trivial anhören mag, aber das war damals für mich einer der wichtigsten Gründe für den Umstieg von Perl auf Python. Mittlerweile hab ich allerdings noch ein paar Gründe mehr. :) > Deshalb finde ich auch JavaScript nicht sooo > sympatisch. Das finde ich auch nicht, hat aber andere Gründe... die Sprache ist leider ziemlich mit der heißen Nadel gestrickt und so Dinge wie diese Prototypen-basierte OOP und so, die sind schon ganz schön gruselig. Nicht zuletzt aus diesen Gründen hat Douglas Crockford, der an JavaScript mitentwickelt hat, das lesenswerte Buch "JavaScript: The Good Parts" geschrieben, wo er sehr deutlich sagt, daß leider nicht alles an JavaScript gelungen sei. > Außerdem gibt es in Python einfach, ich nenne es mal so, > "Unregelmäßigkeiten". Im Prinzip sieht Python so aus, als handele es > sich um eine "schlanke" Sprache bzw. Sprachumgebung. Bei näherem > Hinschauen sehe ich jedoch einige Unstimmigkeiten. Da wäre ich sehr gespannt, welche Du meinst, und möchte Dich sehr gerne darum bitten, noch einmal in Dein Buch zu schauen. Ein Buch von Michael Kofler kann eigentlich nicht so schlecht sein. Wobei, 462 Seiten... das erscheint mir jetzt nicht allzu viel, entweder ist der Lesestoff extrem komprimiert oder er läßt die meisten fortgeschrittenen Dinge aus. Wenn Du ein bisschen Literatur für Fortgeschrittene suchst, empfehle ich wärmstens die Bücher "Fluent Python" von Luciano Ramalho, das sich vielen Interna widmet und etliche wertvolle praktische Tipps und Lösungen zeigt, sowie "Expert Python Programming" von Michal Jaworski und Tarek Ziade, das mit Themen wie der Infrastruktur und dem Projektmanagement beginnt und von da aus eine Reise durch Themen von Metaprogrammierung über eventbasierte und parallele Programierung, die Erweiterung von Python mit C und C++-Code bis hin zur Paketierung und dem Deployment widmet. > Zur Klarstellung: ich werde sicher weiterhin auch in Python > programmieren, aber Python wird wahrscheinlich nicht meine > Lieblingssprache. Das sind schon C(++) und Java ;-) Puh, C und C++ mag ich auch sehr gerne. Aber Java und ich werden sicher keine Freunde mehr in meinem Leben. > Ups wieder ein wenig viel geschrieben. Aber zumindest wir beide schlagen > uns ja immerhin (noch ;-) nicht die Köpfe ein... :-) :-) Es gibt ja auch keinerlei Gründe, sich die Köpfe einzuschlagen. ;)
Stefan F. schrieb: > Wellenleser schrieb: >>> dass wohl niemand größere Programme in Python erstellen will. >> Warum will das keiner? > > Mich hat die praktische Erfahrung mit Odoo abgeschreckt. Die Performance > des Systems war enttäuschend. Wenn ich mich an unser damaliges Gespräch erinnere, hatte Deine Firma diese Software mal kurz ausprobiert, was aber schon damals so lange her war, daß Du leider nichts mehr über die Konfiguration der Software und der Datenbank sagen konntest, was ich damals schon schade gefunden habe. Aaaber auch jetzt bin ich von Deiner Antwort ein wenig enttäuscht, ehrlich gesagt. Du bist ein erfahrener und kompetenter Entwickler und weißt darum sehr genau, daß es nicht sehr klug ist, sich eine Meinung über eine Sprache auf der Basis eines überschaubaren Tests einer Software zu bilden, die in dieser Sprache geschrieben ist. Dies gilt insbesondere dann, wenn dieser Test schon eine ganze Weile her ist und sowohl die Sprache, als auch ihre Implementierungen, und ebenso die getestete Software in dieser Zeit sehr deutlich weiterentwickelt worden sind. Sonst könnte ich ja die uralten GUI-Programme mit dem Abstract Windowing Toolkit (AWT) als Beispiel nehmen und dann behaupten daß Java zu langsam für die Entwicklung von GUI-Software sei. Und wir wissen doch beide, daß das Unfug ist, oder nicht? :)
Karl Käfer schrieb: > Aber in Perl muß ich sehr diszipliniert (und erfahren) sein, um les- und > wartbaren Code zu schreiben, während es in Python genau andersherum ist: > dabei müßte ich mir Mühe geben, wenn ich unlesbar schreiben wollte. So geht es mir mit Python und C++.
Rolf M. schrieb: > So geht es mir mit Python und C++. Ich find' natürlich beides ziemlich zum Kotzen. Wenn ich aber zwischen diesen beiden wählen müßte (und Performance keine Rolle spielen würde, dafür aber Wartbarkeit und Lesbarkeit), würde ich wohl doch eher Python wählen.
Karl Käfer schrieb: > jetzt bin ich von Deiner Antwort ein wenig enttäuscht Es kommt sehr darauf an, was man mit der Programmiersprache anstellt und in welcher Umgebung. Odoo wurde so gebaut, dass die Haupt-Last auf der Datenbank liegt. Damit steht und fällt das ganze Ding. Aber auch das Rendering der Webseiten ist im Vergleich zu C++ und Java auf ähnlichen Servern deutlich langsamer. Mit 20 Gigabytes RAM und 16 Kernen, sowie einem separaten DB Server der mindestens ebenso stark ist, läuft das Programm wahrscheinlich prima. Für mich fühlt sich das allerdings wie eine gewaltige Ressourcenverschwendung an - sehr viel mehr noch, als bei Java EE Anwendungen. Laut diverser Benchmarks ist Python um Faktor 5 bis 20 langsamer als C++. Wenn man 95% der Arbeit an eine DB auslagert, fällt das natürlich nicht mehr so sehr auf. Zudem kann man die Sprache schnell erlernen und relativ schnell damit entwickeln, das ist auch etwas Wert. Ich habe auch mal Micropython auf einem ESP32 ausprobiert, konkret in Form eines "Makeblock Codey Rocky" Roboters. Allerdings habe ich auf viel langsameren kleineren Mikrocontrollern erlebt, wie viel besser Java, Basic und C Bytecode Interpreter performen können. Dagegen kackt Micropython regelrecht ab. Python taugt gut für Glue-Code, der bestehende effiziente Systeme miteinander verkuppelt, oder als GUI für nativ compilierte Programme. Oder halt sonst überall, wo Performance keine große Rolle spielt.
> Oder halt sonst überall, wo Performance keine große Rolle spielt.
Genau meine Meinung! Man muss vielleicht unterscheiden worueber man
redet. Wenn ich von Programmieren rede dann meine ich damit immer
Embedded. Ich meine dies ist www.mikrocontroller.net und nicht
www.webseitengestalter.net. Und dort ist Effizienz natuerlich das
ah und oh.
Bei PC-Software die man dem Kunden rueberreicht kann man vielleicht
sagen ist uns doch schiet egal, soll er sich halt einen besseren Rechner
kaufen wenn seine Kiste zu lahm ist. Oftmal kommt man damit auch
durch.
Olaf
Beitrag #7335064 wurde von einem Moderator gelöscht.
> Die frage nach einem "ranking" ist doof. Es gibt kein universelles > "ranking". Das ist die einzige universelle Wahrheit. Aber aus irgendeinem Grund scheinen Menschen darauf voll abzufahren. Olaf
Stefan F. schrieb: > Es kommt sehr darauf an, was man mit der Programmiersprache anstellt und > in welcher Umgebung. Das stimmt, ist aber eher eine Binsenweisheit. > Odoo wurde so gebaut, dass die Haupt-Last auf der Datenbank liegt. ...und obwohl Du das sogar weißt, ziehst Du aus Deinen Erfahrungen damit einen Rückschluß auf die Sprache, in der Odoo geschrieben ist. Schon das finde ich nicht besonders klug und eines erfahrenen Entwicklers unwürdig, aber noch viel schlimmer finde ich es, daß Du aus der Performance eines Programmes überhaupt auf die Performance einer Sprache rückschließt. Man kann in jeder Sprache ineffizient programmieren, auch in Assembler, C/C++ und natürlich auch in Java. > Damit > steht und fällt das ganze Ding. Aber auch das Rendering der Webseiten > ist im Vergleich zu C++ und Java auf ähnlichen Servern deutlich > langsamer. Odoo benutzt ausweislich seiner Dokumentation eine eigene Templateengine namens QWeb, und ein kurzer Blick in dessen Dokumentation zeigt, daß das Ding wahrscheinlich nicht sonderlich performant sein kann. Es gibt aber andere etablierte Template-Engines für Python wie etwa Jinja2, das auch dank Kompilierung und Caching als sehr performant gilt und nach allem, was ich gelesen habe, sogar schneller als bekannte Java-Templateengines wie Apache Velocity und FreeMarker sein soll. > Mit 20 Gigabytes RAM und 16 Kernen, sowie einem separaten DB Server der > mindestens ebenso stark ist, läuft das Programm wahrscheinlich prima. Wenn man die Software nicht entsprechend konfiguriert: nein, dann wird es nicht performant laufen. Odoo läuft ausweislich seiner Dokumentation in der Standardeinstellung mit nur einem Worker und dem entsprechend starten alle Dokumente zum Performance Tuning, die ich gelesen habe, mit dem Hinweis, die Nutzung mehrerer Threads zu aktivieren. Ähnliches gilt auch für PostgreSQL, das mit einer sehr, sehr, sehr, sehr konservativen Standardkonfiguration ausgeliefert wird. Unter Ubuntu 22.04 beispielsweise ist die Standardkonfiguration von PostgreSQL so, daß sie auf lediglich 256 MB Arbeitsspeicher ausgelegt ist. So sagt dann auch die Seite "Tuning Your PostgreSQL Server" im Wiki von PostgreSQL mit den Sätzen: "PostgreSQL ships with a basic configuration tuned for wide compatibility rather than performance. Odds are good the default parameters are very undersized for your system." (Quelle: [1]) [1] https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server > Für mich fühlt sich das allerdings wie eine gewaltige > Ressourcenverschwendung an - sehr viel mehr noch, als bei Java EE > Anwendungen. > > Laut diverser Benchmarks ist Python um Faktor 5 bis 20 langsamer als > C++. Benchmarks, die solche Größenordnungen belegen, sind mir unbekannt, und obendrein sind Benchmarks ja ohnehin nur begrenzt aussagekräftig für die Performance von Anwendungen aus der echten Welt. Aber schauen wir uns doch mal diese [2] Benchmarks an, die dem "Benchmarks Game" von Debian ähneln und Python und Java gegenüberstellen. Der geneigte Leser erkennt schnell: je nach Python-Interpreter und der Kombination aus Java Runtime Environment und Garbage Collector ist Python oft sogar schneller als Java, und Python benötigt in fast allen Fällen bedeutend weniger Arbeitsspeicher -- von wegen Ressourcenverschwendung... [2] https://programming-language-benchmarks.vercel.app/python-vs-java > Wenn man 95% der Arbeit an eine DB auslagert, fällt das natürlich > nicht mehr so sehr auf. Zudem kann man die Sprache schnell erlernen und > relativ schnell damit entwickeln, das ist auch etwas Wert. ...und wenn es eine riesengroße und gut organisierte Infrastruktur gibt, die sicherlich auch einer der Hauptgründe für die Beliebtheit von Python ist. Wenn ich unter Java oder C++ eine CSV- oder JSON-Datei parsen will, muß ich mich erst einmal auf die Suche nach einer Bibliothek begeben und einige testen, bis ich etwas passendes gefunden habe. In Python gehören viele Bibliotheken für derlei Standardaufgaben zur Standardinstallation -- und sind keinen Deut langsamer als nativer Maschinencode, denn sie sind intern als Shared Objects (DLLs unter Windows) in C oder C++ geschrieben. > Python taugt gut für Glue-Code, der bestehende effiziente Systeme > miteinander verkuppelt, oder als GUI für nativ compilierte Programme. > Oder halt sonst überall, wo Performance keine große Rolle spielt. Es kommt, wie Du bereits eingangs erwähnt hast, natürlich immer passende Werkzeuge für entsprechende Anwendungsfälle. Aber im Kern muß man sagen, daß es viele Möglichkeiten gibt, performanten Python-Code zu schreiben und existierenden Code zu beschleunigen. Das reicht von der Einbindung nativen C- und C++-Codes über die Kompilation von Pythoncode, wahlweise speziell für bestimmte Bereiche wie rechenlastigen Code bis hin zur Möglichkeit, ganze Python-Programme erst in C/C++ zu transpilieren und dann mit einem C- oder C++-Compiler in nativen Code zu ersetzen. Insofern glaube ich, daß Du Python und seine Leistungsfähigkeit deutlich unterschätzt. Und wenn Du in die Liste von Python-Software der Wikipedia [3] schaust, siehst Du da eine ganze Reihe von mitunter sehr großen, leistungsfähigen Pyton-Programmen, die sicherlich nicht alle nur "Glue-Code" sind und bei denen Performance durchaus hie und da eine große Rolle spielt. [3] https://en.wikipedia.org/wiki/List_of_Python_software Was denkst Du denn, warum Python gerade in Bereichen wie Data Science und Big Data so beliebt ist? Weil die Leute dort nur Glue-Code schreiben und Performance in diesen Umfeldern keine Rolle spielt? Das Gegenteil trifft zu: gerade dort, wo große und größte Datenmengen mit oft sehr komplexen Berechnungen verarbeitet werden, ist Python mittlerweile ganz besonders beliebt und hat sogar den Platzhirsch R weitgehend verdrängt. Warum nur? Richtig: weil Du Pythons Leistungsfähigkeit deutlich unterschätzt und es dank seiner herausragenden Infrastruktur Dinge leisten kann, welche mit anderen Sprachen nur mit wesentlich größerem Aufwand machbar sind.
Karl Käfer schrieb: > DenkenMachtSpaß schrieb: [...] >> Meine subjektive Meinung: Mir sind Sprachen mit dynamischer Typisierung >> immer ein wenig suspekt. > > Das höre ich sehr häufig von Entwicklern, die von statisch typisierten > Sprachen kommen, und als ich damals von C/C++ zu Perl kam, hat mich das > anfangs auch abgeschreckt. Aber in meiner Zeit mit Perl habe ich > gelernt, daß das gar kein so großes Thema war wie gedacht. Man gewöhnt sich halt dran ;-) [...] >> Außerdem gibt es in Python einfach, ich nenne es mal so, >> "Unregelmäßigkeiten". Im Prinzip sieht Python so aus, als handele es >> sich um eine "schlanke" Sprache bzw. Sprachumgebung. Bei näherem >> Hinschauen sehe ich jedoch einige Unstimmigkeiten. > > Da wäre ich sehr gespannt, welche Du meinst, und möchte Dich sehr gerne > darum bitten, noch einmal in Dein Buch zu schauen. Also ich habe die Kapitel, die ich bereits gelesen habe, nochmal überflogen. Ich muss zugeben: beim zweiten Hinschauen waren die "Unregelmäßigkeiten" doch nicht so gravierend und häufig. Kurz notiert habe ich mir (ohne jetzt nochmal groß darüber nachzudenken, deshalb bitte ich um Nachsicht, wenn ich eleganten Möglichkeiten übersehen habe): - Keine (echten) Konstanten - Die Type Annotations in Funktionsdef. und Variablendef. sind halt nur Hinweise und hindern dich nicht dran, was böses zu tun. - die komische print-Syntax mit "%" zwischen Formatzeichenkette und den auszugebenden Werten. - Na, ist ja nett, dass es zwei Systeme zur Formatierung gibt (printf-Style vs. .Net-Style.) Aber welches soll ich denn nun nehmen? Ehrlich gesagt kenne ich den .Net-Style nicht. Muss mich da auch erst mal einlesen. - die Kontstruktor-Syntax (_init_) finde ich a bissle seltsam (rein optisch). Was mich aber stört ist, dass die Klassenmethoden immer mit explizitem "self" definiert werden müssen. Das sieht ein wenig wie "objektorientierte Programmierung mit einer prozeduralen Sprache" aus. - kein Switch - Keine privaten Attribute bzw. Variablen. Da wird dann lexikalisch versucht, das Poblem zu entschärfen mit _ bzw. __ (name Mangling). Na ja. Wirkt auf mich nicht gerade elegant. Bei Python hat man ja zwischen 2 und 3 erhebliche Kompatibilität aufgegeben. Warum hat man dann in dem Zug nicht gleich solche "Baustellen" aufgeräumt? So richtig eingelesen in die Thematik Exceptions habe ich mich noch nicht. Beim überfliegen sah es jedenfalls etwas seltsam aus. Aber ich muss sagen, meine Einstellung hat sich etwas geändert. Man kann viele Sachen dank der umfangreichen Standard-Lib und pip doch recht unkompliziert umsetzen. Aaaaber: Optisch sieht Python-Quelltext grottig aus, da bleibe ich dabei, auch wenn die restlichen 99,9999% der Anwender genau der gegenteiligen Meinung sind. Da ist selbst das geschwätzige Pascal mit Begin und End noch besser. Und ICH liebe meine curly braces :-) > Ein Buch von Michael > Kofler kann eigentlich nicht so schlecht sein. Ist er auch nicht! Ist im recht handlichen Format. Ich brauche eigentlich bei neuen Sprachen immer nur eine verständliche Einführung, die ich in die Hand nehmen kann. Später nutzt man ja sowieso nur noch die Online-Doku. Mir gefällt an diesem Büchlein, dass es sich nicht um ein aufgeblähtes Bilderbuch handelt, sondern der Inhalt kurz und prägnant mit wenigen, aber nützlichen Abbildungen und Tabellen dargestellt wird. Das entspricht am ehesten meiner persönlichen Lernmethodik. Ich kenne halt den "Kofler" (Linux-Buch) schon seit vielen Jahren und habe mich an den Schreibstil gewöhnt. Wobei, 462 Seiten... das > erscheint mir jetzt nicht allzu viel, entweder ist der Lesestoff extrem > komprimiert oder er läßt die meisten fortgeschrittenen Dinge aus. Beides! :-) Aber wie gesagt genau richtig für mich. Ich brauche kein Buch, das die komplette Library Reference abdruckt. > > Wenn Du ein bisschen Literatur für Fortgeschrittene suchst, empfehle ich > wärmstens die Bücher "Fluent Python" von Luciano Ramalho, das sich > vielen Interna widmet und etliche wertvolle praktische Tipps und > Lösungen zeigt, sowie "Expert Python Programming" von Michal Jaworski > und Tarek Ziade, das mit Themen wie der Infrastruktur und dem > Projektmanagement beginnt und von da aus eine Reise durch Themen von [...] Danke für den Tipp. Da schaue ich mal rein, wenn ich an die Bücher komme. [...] > Puh, C und C++ mag ich auch sehr gerne. Aber Java und ich werden sicher > keine Freunde mehr in meinem Leben. C++ ja, aber Java nein?! Wie das? Das einzige, was mich am Anfang abgeschreckt hat in Java, ist die GC. Aber man sieht ja, dass es funktioniert. [...] > Es gibt ja auch keinerlei Gründe, sich die Köpfe einzuschlagen. ;) Eben! In anderen Threads und Foren scheint das allerdings Hauptzweck zu sein. Dass die Mods da selten einschreiten, ist ja auch klar. Die wollen auch blos Quote ;-) Viele Grüße Marcus
DenkenMachtSpaß schrieb: > Außerdem gibt es in Python einfach, ich nenne es mal so, > "Unregelmäßigkeiten". DenkenMachtSpaß schrieb: > Kurz notiert habe ich mir (ohne jetzt nochmal groß darüber > nachzudenken, deshalb bitte ich um Nachsicht, wenn ich eleganten > Möglichkeiten übersehen habe): > ... Zwei Hinweise (die keine Kritik an deiner Kritik sein sollen): > - die komische print-Syntax mit "%" zwischen Formatzeichenkette und den > auszugebenden Werten. Dar "%"-Operator hat nichts direkt mit print zu tun, sondern ist das aus C bekannte sprintf umformuliert als binärer Operator: Die C-Anweisung
1 | sprintf(str, fmt, x, y, z); |
hat das Python-Äquivalent
1 | str = fmt % (x, y, z) |
In Verbindung mit print wird daraus ein printf-Ersatz und in Verbindung mit write ein fprintf-Ersatz. Da die Argumente als Tuple übergeben werden, sind damit auch vprintf, vsprintf und vfprintf abgedeckt. Seit einiger Zeit gibt es als Alternative die f-Strings, bei denen das Format und die zu formatierenden Werte eine Einheit bilden. Beispiel:
1 | >>> x = 3 |
2 | >>> y = 4 |
3 | >>> f'Die Summe von {x} und {y} ist {x+y}.'
|
4 | 'Die Summe von 3 und 4 ist 7.' |
Wem das Einflechten der Argumente in den Formatstring unsympathisch ist, kann die Argumente mittels der format.Funktion auch hinten anstellen:
1 | 'Die Summe von {} und {} ist {}.'.format(x, y, x+y)
|
Welche der drei Schreibweisen verwendet wird, ist etwas Geschmackssache,
wobei lt. Doku die beiden neueren (.format() und f-String) bevorzugt
werden sollten.
Die {}-Syntax in den Formatstrings ist hier spezifiziert:
https://docs.python.org/3/library/string.html#formatstrings
> - kein Switch
Es hat zwar lange gedauert, aber seit Python 3.10 gibt es match-case,
das wie switch-case genutzt werden kann:
1 | def f(x): |
2 | match x: |
3 | case 1: |
4 | print('eins')
|
5 | case 2: |
6 | print('zwei')
|
7 | case 3: |
8 | print('drei')
|
Match-case ist aber sehr viel mächtiger als switch-case in C: https://peps.python.org/pep-0636/
Yalu X. schrieb: > Zwei Hinweise (die keine Kritik an deiner Kritik sein sollen): Wer Kritik nicht verträgt sollte nicht öffentlich Meinungen kundtun. ;-) Kommt halt drauf an, wie die Kritik aussieht: "geh sterben du Drecksarschloch"(*) wäre mir z.B. etwas too much. > >> - die komische print-Syntax mit "%" zwischen Formatzeichenkette und den >> auszugebenden Werten. > > Dar "%"-Operator hat nichts direkt mit print zu tun, sondern ist das aus > C bekannte sprintf umformuliert als binärer Operator: > > Die C-Anweisung > sprintf(str, fmt, x, y, z); > > hat das Python-Äquivalent > str = fmt % (x, y, z) Ah, dachte ich mir doch, dass der %-OP überladen ist. Gut, dass es in Java keine OP-Überladung gibt. (Jetzt mal im Ernst: ich persönlich finde es bedauerlich, dass es keine OP-Überladung in Java gibt!) Nochmal danke für Deine weiteren Erläuterungen. Gruß Marcus (*) Mal sehen, ob hier ein automatischer Aufpasser drüber läuft und was die Mods machen.
DenkenMachtSpaß schrieb: > Ah, dachte ich mir doch, dass der %-OP überladen ist. > Gut, dass es in Java keine OP-Überladung gibt. > (Jetzt mal im Ernst: ich persönlich finde es bedauerlich, dass es keine > OP-Überladung in Java gibt!) Besser überhaupt keine Operatorüberladung als eine, die zum Missbrauch einlädt wie in Python oder C++. Eine Formatierung als Modulo-Operation (Python), eine Stream-I/O als Bitshift (C++) oder ein Datum als Division (C++) zu schreiben, ist einfach nur grober Unfug und fördert keineswegs die Verständlichkeit des Codes. Java hat das Problem auf einfache Weise gelöst, indem es den Blödsinn gar nicht erst von C++ übernommen hat. Haskell hat das Problem besser gelöst, indem es die Verwendung derselben Operatoren für verschiedene Datentypen zwar zulässt, aber nur dann, wenn diese Datentypen miteinander verwandt sind, d.h. zur selben Typklasse gehören (bspw. "+", "-" und "*" nur für numerische Typen). Wenn für eine neue Operation die existierenden Operatoren nicht passen, gibt es die Möglichkeit, neue Operatoren zu definieren.
Yalu X. schrieb: > fördert keineswegs die Verständlichkeit des Codes. Ja, dafür hätte ich dir gerne +5 gegeben > Java hat das Problem auf einfache Weise gelöst, >indem es den Blödsinn gar nicht erst von C++ übernommen hat. Und ich habe wiederum von Java gelernt, dass man es auch nicht braucht. Ergo verzichte ich in meinen C++ Programm darauf.
DenkenMachtSpaß schrieb: > Karl Käfer schrieb: >> DenkenMachtSpaß schrieb: > [...] >>> Meine subjektive Meinung: Mir sind Sprachen mit dynamischer Typisierung >>> immer ein wenig suspekt. >> >> Das höre ich sehr häufig von Entwicklern, die von statisch typisierten >> Sprachen kommen, und als ich damals von C/C++ zu Perl kam, hat mich das >> anfangs auch abgeschreckt. Aber in meiner Zeit mit Perl habe ich >> gelernt, daß das gar kein so großes Thema war wie gedacht. > > Man gewöhnt sich halt dran ;-) Klar, aber die eigentliche Frage ist ja, ob man das wirklich braucht. Dabei liefern viele Skriptsprachen von Perl über Ruby, PHP und JavaScript bis hin zu eben auch Python eine eindeutige Antwort: nein, das braucht man nicht wirklich, und daß viele Entwickler daran gewöhnt sind, ändert daran auch nichts. Man kann stabile, funktionsfähige und auch recht schnelle Programme mit anderen Typsystemen schreiben und dabei meistens auch schneller entwickeln, da das dem Entwickler viel Arbeit ersparen kann. Andererseits bieten einige der erwähnten Sprachen, darunter Python, auch dank ihrer starken Fähigkeiten zur Introspektion durchaus Möglichkeiten für Leute, die nun trotzdem nicht glauben wollen, daß es auch ohne geht. Wenn Du magst, schau Dir vielleicht mal fortgeschrittene Themen wie die Library Attrs ([1]), das (eher fortgeschrittene) Thema Deskriptoren [2] an sowie den Typechecker Mypy [3] an. [1] https://www.attrs.org/en/stable/ [2] https://docs.python.org/3/howto/descriptor.html [3] https://mypy-lang.org/ > Also ich habe die Kapitel, die ich bereits gelesen habe, nochmal > überflogen. Ich muss zugeben: beim zweiten Hinschauen waren die > "Unregelmäßigkeiten" doch nicht so gravierend und häufig. Ja, auf den zweiten Blick wirken manche Dinge dann eben doch nicht mehr so exotisch wie auf den ersten. ;) > Kurz notiert > habe ich mir (ohne jetzt nochmal groß darüber nachzudenken, deshalb > bitte ich um Nachsicht, wenn ich eleganten Möglichkeiten übersehen > habe): Ich kürze an dieser Stelle mal ab, um keine tldr-Textwüste zu provozieren, und gehe im Folgenden nurmehr auf einige besondere Punkte ein. Im Grunde genommen sehe ich viele Deiner Einwände allerdings primär als Folge der Tatsache, daß Du Pythons Syntax nicht magst, und daß einige Entscheidungen der Python-Entwickler Dir nicht gefallen. Die Hintergründe vieler dieser Entscheidungen sind allerdings dokumentiert und erläutert in den "Python Enhancement Proposals" (PEP), insbesondere der PEPs 8 [4] und 20 [5]. In vielen Fällen geht es darum, Python als Sprache so lesbar und so einfach wie möglich zu halten, nicht allzu viele Keywords einzuführen, und viele Dinge per Konvention zu behandeln. [4] https://peps.python.org/pep-0008/ [5] https://peps.python.org/pep-0020/ > - Die Type Annotations in Funktionsdef. und Variablendef. sind halt nur > Hinweise und hindern dich nicht dran, was böses zu tun. Das tun sie etwa in C++ auch nicht: wenn ich unbedingt auf eine als private oder protected deklarierte Eigenschaft oder Methode zugreifen will, kann ich diesen Teil des Typsystems recht einfach umgehen, denn die Typprüfung findet ja nur zur Compilezeit statt. > - Na, ist ja nett, dass es zwei Systeme zur Formatierung gibt > (printf-Style vs. .Net-Style.) Aber welches soll ich denn nun nehmen? > Ehrlich gesagt kenne ich den .Net-Style nicht. Muss mich da auch erst > mal einlesen. Ich kenne den .NET-Stil auch nicht und das Framework nur dem Namen nach, aber im Wesentlichen gibt es sogar mindestens fünf eingebaute Lösungen: 1. Die %-Syntax (die zwar häufig mit print() verwendet wird, aber davon komplett unabhängig ist, 2. die .format()-Methode der Builtin-Klasse str, 3. die f-Strings, 4. die (eher unbekannte) Klasse string.Template, 5. die Konkatenation ("eins =" + str(1) + " zwei =" + str(2)). Die print()-Funktion bietet sogar die Möglichkeit, die Argumente einfach als mit Kommata getrennt, also als Parameterliste *args zu übergeben: print("eins =", 1, "zwei =", 2) Achtung: hier wird zwischen den Argumenten standardmäßig je ein Leerzeichen ausgegeben, was sich aber mit dem Parameter "sep" steuern läßt. > - die Kontstruktor-Syntax (_init_) finde ich a bissle seltsam (rein > optisch). Was mich aber stört ist, dass die Klassenmethoden immer mit > explizitem "self" definiert werden müssen. Das ist schon durchaus sinnvoll, weil es a) ein Schlüsselwort spart ("self" ist nur die Konvention, Du kannst es auch "karl", "klaus", oder "dieter" nennen -- aber Vorsicht: solche Verstöße gegen die Konvention könnten dazu führen, daß Du Dich vor einem Mob mit Fackeln und Mistforken in Sicherheit bringen mußt). Und b) weil es statische und Klassenmethoden ermöglicht, die dann im Falle von statischen Methoden keinen vorgesehenen ersten Parameter haben und im Falle von Klassenmethoden eben die Klasse (per Konvention in der Regel mit "cls" benannt). Natürlich hätte man das auch anders machen können, aber es ist konsistent mit den anderen "magischen Methoden" wie _del_ und den Möglichkeiten zum Überschreiben von Operatoren wie in "__call__" oder "__add__". Nun kann man lange darüber diskutieren, ob die Überladung von Operatoren sinnvoll oder gar notwendig ist, aber nach meiner Erfahrung ist das in manchen Fällen sinnvoll und führt zu kürzerem, einfacherem und besser lesbarem Code. Man darf sie nur nicht für unerwartete Dinge mißbrauchen, dann geht das schon. > - kein Switch Seit Version 3.10 bietet Python die Möglichkeit des sogenannten Structural Pattern Matching, spezifiziert in den PEPs 634 bis 636 [6,7,8], allerdings empfehle ich, mit PEP 636 anzufangen. Du wirst sehen: das bietet sehr viel mehr Möglichkeiten als die üblichen Switch-Statements in Sprachen wie etwa C, C++, oder Java. [6] https://peps.python.org/pep-0634/ [7] https://peps.python.org/pep-0635/ [8] https://peps.python.org/pep-0636/ > Aber ich muss sagen, meine Einstellung hat sich etwas geändert. Man kann > viele Sachen dank der umfangreichen Standard-Lib und pip doch recht > unkompliziert umsetzen. Ja, das kann man unbedingt, und nach ein bisschen Übung kenne ich auch keine andere Sprache, mit der das so schnell geht. > Aaaaber: Optisch sieht Python-Quelltext grottig aus, da bleibe ich > dabei, auch wenn die restlichen 99,9999% der Anwender genau der > gegenteiligen Meinung sind. Da ist selbst das geschwätzige Pascal mit > Begin und End noch besser. Und ICH liebe meine curly braces :-) Das ist zweifellos eine Frage des persönlichen Geschmacks, den ich Dir gar nicht absprechen oder gar madig machen möchte. Auch für mich war das zu Beginn durchaus ein Punkt, aber mit der Zeit und der Gewohnheit habe ich meine Ansicht dazu geändert. Der große Vorzug dieser verknappten Syntax ist, daß sie einen zu sauberen Einrückungen und damit zu sauberem Code zwingt, und außerdem eine Reihe Sonderzeichen einspart, die sich auf dem deutschen Tastaturlayout zudem nur mit Verrenkungen tippen lassen (darum habe ich früher gerne zum Entwickeln ein englisches Layout eingestellt). > Ich kenne halt > den "Kofler" (Linux-Buch) schon seit vielen Jahren und habe mich an den > Schreibstil gewöhnt. Das ist im Übrigen auch das Standardwerk, das ich jedem Linux-Einsteiger wärmstens ans Herz lege. :) >> Puh, C und C++ mag ich auch sehr gerne. Aber Java und ich werden sicher >> keine Freunde mehr in meinem Leben. > > C++ ja, aber Java nein?! Wie das? Das einzige, was mich am Anfang > abgeschreckt hat in Java, ist die GC. Aber man sieht ja, dass es > funktioniert. Java ist so eine Sprache, mit der ich gewisse Schwierigkeiten habe. Dort gibt es beispielsweise keine Mehrfachvererbung, weil die Entwickler von Java sie für nicht besonders nützlich und obendrein für zu schwierig für die Nutzer ihrer Sprache gehalten haben, ähnliches gilt für das Überladen von Operatoren, zu dem ich ja schon etwas gesagt habe. Zum Leidwesen von meinen damaligen Vorgesetzen habe ich Java nie gemocht und hätte es lieber gesehen, wenn einige seiner Konzepte wie der plattformunabhängige Bytecode oder eine, dann natürlich optionale, automatische Garbage Collection für C++ umgesetzt worden wären. Und die Garbage Collection von Java ist leider auch so eine Sache, die einem bei realen Echtzeitanforderungen regelmäßig auf die Füße fällt. In einer mir gründlich bekannten Serversoftware zur Betrugsprävention, die auch im Echtzeitpfad von Kreditkartenzahlungen verwendet wird, kommt es leider in unregelmäßigen Abständen dazu, daß die GC zuschlägt und dabei eine Art "Stop the world" ausführt, so daß der Rechner für diese Zeit keinerlei Transaktionen annimmt, verarbeitet, oder ausgibt. Da bei dieser Software die Karten- und Händlerhistorien aus Performancegründen im Arbeitsspeicher gehalten werden und die Prozesse daher durchaus auch mal einige Terabyte Arbeitsspeicher nutzen, dauert die GC dann natürlich auch entsprechend lange. Immerhin scheint die neueste Version des GC, der Zero Garbage Collector, einige dieser Probleme zu verbessern, allerdings hatte dieser in seinen Anfangszeiten noch mitunter Memory Leaks. Trotzdem: daß es den Entwicklern von Java erst nach 25 Jahren Entwicklungszeit gelungen zu sein scheint, einen stabilen, schnellen, parallelen und stabilen Garbage Collector zu entwickeln, ist IMHO ein deutliches Zeichen dafür, wie problembehaftet der grundsätzliche Ansatz der automatischen Speicherbereinigung ist. Das hätte man auch optional machen können, und es gibt ja auch einige Ansätze im Netz, bei denen große Speicherchunks allokiert und dann manuell verwaltet werden, um solche Probleme umgehen zu können. > Eben! In anderen Threads und Foren scheint das allerdings Hauptzweck zu > sein. Dass die Mods da selten einschreiten, ist ja auch klar. Die wollen > auch blos Quote ;-) Entschuldige, aber nein, das glaube ich nicht. Sie sind nur leider viel, viel, viel zu wenige... und zudem an die Anweisungen eines Betreibers mit einer scheinbar recht hohen Toleranzschwelle gebunden. Jedenfalls danke für diese angenehm ruhige und sachliche Diskussion und ich hoffe, ich konnte Dir einige meiner Ansichten erläutern, auch wenn mein Beitrag trotz meiner Bemühungen leider doch wieder eine Textwüste geworden ist! ;)
Karl Käfer schrieb: [...] > Das tun sie etwa in C++ auch nicht: na ja, aber die Hürden sind schon ein wenig höher wie ein Unterstrich oder einfach (de)mangling. [...] > gibt es beispielsweise keine Mehrfachvererbung, weil die Entwickler von Mit Klassen nicht, aber mit Interfaces. Zwar nicht optimal, aber prinzipiell geht es. > Java sie für nicht besonders nützlich und obendrein für zu schwierig für > die Nutzer ihrer Sprache gehalten haben, ähnliches gilt für das > Überladen von Operatoren, zu dem ich ja schon etwas gesagt habe. Ja, diese "Bevormundung" finde ich auch bescheiden. C++ wird ja oft gerade der gegenteilige Vorwurf gemacht: "Man hat zu viele Freiheiten". Die Leute, die so argumentieren, scheinen zu übersehen, dass die Verwendung von komplexen Kontrukten in C++ kein "Muss", sondern ein "Du kannst wenn Du willst" ist. Konnte noch nie nachvollziehen, wenn Leute den Sprachumfang kritisieren. OK, der Einstieg wird ein wenig aufwendiger, wenn man das falsche Tutorial liest. ;-) [...] > Und die Garbage Collection von Java ist leider auch so eine Sache, die > einem bei realen Echtzeitanforderungen regelmäßig auf die Füße fällt. Das ist aber jammern auf hohem Niveau ;-) Mag sein, dass in der Vergangenheit der GC in extremen Einsatzbereichen ein Problem war. Aber aktuell mache ich mir bei "normalen" Anwendungen keinen Gedanken mehr über den GC (und habe ich ehrlich gesagt auch nie gemacht). [...] Das Thema "Mods": es wurden halt schon völlig harmlose, themenbezogene Postings von mir gelöscht. Und wüste Beschimpfungen bleiben unangetastet. Aber ich habe jetzt beim Querlesen verschiedener Thread gesehen, dass schon ab und zu gelöscht wird. Also alles OK. Ich bedanke mich auch für den netten Thread, Karl! Viele Grüße Marcus
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.