Forum: Compiler & IDEs Sprachen Ranking


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Veit D. (devil-elec)


Lesenswert?

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

von DenkenMachtSpaß (Gast)


Lesenswert?

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

von löppt (Gast)


Lesenswert?

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.
von Wilhelm M. (wimalopaan)


Lesenswert?

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

von Olaf (Gast)


Lesenswert?

> 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

von Gustl Germanium (Gast)


Lesenswert?

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'.

von Rolf M. (rmagnus)


Lesenswert?

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
von vancouver (Gast)


Lesenswert?

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.

von asd (Gast)


Lesenswert?

> 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.

von Michael B. (laberkopp)


Lesenswert?

DenkenMachtSpaß schrieb:
> dass wohl niemand größere Programme in Python erstellen will.

Alles, was man in Python erstellt, ist gross.

von Gerhard O. (gerhard_)


Lesenswert?

Michael B. schrieb:
> gross

"gross' wie in "disgusting" oder "pfui"?;-)

von Beides, wír spielen Country und Western (Gast)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

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
von Beides, wír spielen Country und Western (Gast)


Lesenswert?

> 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.

von DenkenMachtSpaß (Gast)


Lesenswert?

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

von DenkenMachtSpaß (Gast)


Lesenswert?

straight

von Elektrokurt (Gast)


Lesenswert?

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.

von olaf (Gast)


Lesenswert?

> 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

von Uwe D. (monkye)


Lesenswert?

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.

von Karl Käfer (Gast)


Lesenswert?

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

von Karl Käfer (Gast)


Lesenswert?

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.

von Karl Käfer (Gast)


Lesenswert?

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.

von rbx (Gast)


Lesenswert?

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)

von Karl Käfer (Gast)


Lesenswert?

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.

von DenkenMachtSpaß (Gast)


Lesenswert?

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

von Wellenleser (Gast)


Lesenswert?

DenkenMachtSpaß schrieb:
> dass wohl niemand größere Programme in Python
> erstellen will.

Warum will das keiner?

von Stefan F. (Gast)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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.

von Harald W. (wilhelms)


Lesenswert?

Olaf schrieb:

> Und da wird halt auch noch viel in Basic programmiert.

Wurde die Textverarbeitung "Word" nicht früher auch mit Basic 
geschrieben?

von Da Baby (Gast)


Lesenswert?

Python wenns schnell gehen muss. Fürs Prototyping auch ganz nice.

von Karl Käfer (Gast)


Lesenswert?

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. ;)

von Karl Käfer (Gast)


Lesenswert?

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? :)

von Rolf M. (rmagnus)


Lesenswert?

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++.

von c-hater (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Olaf (Gast)


Lesenswert?

> 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.
von Olaf (Gast)


Lesenswert?

> 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

von Ein T. (ein_typ)


Lesenswert?

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.

von DenkenMachtSpaß (Gast)


Lesenswert?

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

von Yalu X. (yalu) (Moderator)


Lesenswert?

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/

von DenkenMachtSpaß (Gast)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Karl Käfer (Gast)


Lesenswert?

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! 
;)

von DenkenMachtSpaß (Gast)


Lesenswert?

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

Bitte 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
Noch kein Account? Hier anmelden.