Forum: PC-Programmierung Welche Programmiersprache für numerische Rechnungen


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 Fritz G. (fritz65)


Lesenswert?

Mal eine eher allgemeine Frage:

Welche Programmmiersprache wird heute für Software mit hohem numerischen 
Rechenaufwand, beispielsweise Wetter- und Klimasimulationen oder 
Quantenchemie, verwendet? Zu meiner Studienzeit war Fortran das Mass 
aller Dinge, mit oft steinzeitlichem, über Jahrzehnte immer wieder 
ergänztem Code.

Ich muss zugeben, dass ich mich seit dem letzten Jahrtausend nicht mehr 
mit derartig aufwändigen Rechnungen beschäftigt habe, was an Numerik 
anfiel, konnte ich seitdem mit Matlab erschlagen.

Was würde man heute nehmen, wenn man eine klassische "number 
crunching"-Anwendung neu schreiben würde? C(++) ist zwar weit 
verbreitet, aber für numerische Rechnung (z.B. lineare Algebra) eher 
umständlich. Ist Python eine Alternative?
Fortran wurde ja auch ständig weiterentwickelt, die modernen Versionen 
haben kaum noch etwas mit dem vorsintflutlichen F77 oder früher 
gemeinsam. Aber nutzt das jemand?

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Dann und wann bau' ich mir mal ein GNU-Octave (=Matlab fuer Bargeldarme) 
aus sourcen; dabei kann man feststellen, dass schon noch ganz ordentlich 
Zusatzlibs benoetigt werden, die immernoch in Fortran geschrieben 
sind...

Gruss
WK

von Re D. (re_d228)


Lesenswert?

Fritz G. schrieb:
> C(++) ist zwar weit verbreitet, aber für numerische Rechnung (z.B.
> lineare Algebra) eher umständlich. Ist Python eine Alternative?

Numpy ist in C/C++ geschrieben.

von Michael B. (laberkopp)


Lesenswert?

Fritz G. schrieb:
> Was würde man heute nehmen, wenn man eine klassische "number
> crunching"-Anwendung neu schreiben würde?

Eine GPU.

Dir geht es ja scheinbar nicht um hohe Präzision aka viele Stellen, 
womöglich arbitrary numbers,

sondern um Tempo, durchaus mit kleinen eventuell sogar Intergerwerten.

Wenn man da kein speziall für die Aufgabe programmiertes FPGA nutzt, 
dann eben eine GPU, wie sie als Bitcoin Miner oder CUDA 
https://de.wikipedia.org/wiki/CUDA
eingesetzt werden.

von 1N 4. (1n4148)


Lesenswert?

> Numpy ist in C/C++ geschrieben.

WIMRE benutzen zugrundeliegende BLAS-Libraries gerne noch Fortran

von Vanye R. (vanye_rijan)


Lesenswert?

> Was würde man heute nehmen, wenn man eine klassische "number
> crunching"-Anwendung neu schreiben würde?

Du koenntest ja mal das hier probieren:

https://de.wikipedia.org/wiki/Julia_(Programmiersprache)

Vanye

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Fritz G. schrieb:
> Fortran wurde ja auch ständig weiterentwickelt, die modernen Versionen
> haben kaum noch etwas mit dem vorsintflutlichen F77 oder früher
> gemeinsam.

Der dafür geschriebene Code schon. Schau mal in die ganzen Bibliotheken 
für lineare Algebra rein, das wimmelt nach wie vor von kryptischen 
Bezeichnern, weil man ja alles in 6 (signifikante) Zeichen rein pressen 
musste dazumals.

1N 4. schrieb:
>> Numpy ist in C/C++ geschrieben.
>
> WIMRE benutzen zugrundeliegende BLAS-Libraries gerne noch Fortran

So isses. Der wesentliche Verdienst von Python hier dürfte es sein, ein 
Bindeglied für die alten FORTRAN-Bibliotheken ins 21. Jahrhundert 
ahzubieten. Da es außerdem noch ein Bindeglied zu arbiträr großen 
Ganzzahlen bietet, ist es rund herum recht universell benutzbar.

von Giovanni (sqrt_minus_eins)


Lesenswert?

Fritz G. schrieb:
> Welche Programmmiersprache wird heute für Software mit hohem numerischen
> Rechenaufwand, beispielsweise Wetter- und Klimasimulationen oder
> Quantenchemie, verwendet?

meine Empfehlung: https://docs.sciml.ai/ModelingToolkit/stable/

Nach FORTRAN, C, Octave, Python bin ich jetzt dort gelandet. JULIA hat 
Suchtpotential - erfordert aber ein Umdenken.

Die Entwicklung wird getrieben vom MIT, CERN ,... und anderen 
Forschungseinrichtungen.

https://julialang.org/   und
https://juliacon.org/2024/   - Videos findet man auf youtube.

: Bearbeitet durch User
von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

Fritz G. schrieb:
> Ich muss zugeben, dass ich mich seit dem letzten Jahrtausend nicht mehr
> mit derartig aufwändigen Rechnungen beschäftigt habe, was an Numerik
> anfiel, konnte ich seitdem mit Matlab erschlagen.

Vielleicht sollte man erwähnen, dass sich seit dem letzten Jahrtausend 
auch geändert hat was als "aufwendige Rechnungen" gilt.

Bist du dir sicher, dass deine "aufwendigen Rechnungen" heute noch als 
aufwendig gelten? Wenn deine Anforderungen an "aufwendig" nicht 
gestiegen sind, dann kannst du das, überspitzt dargestellt, heutzutage 
skripten. Du musst dir keine großen Gedanken um die Sprache machen. Nimm 
die die du am bequemsten findest.

Um mal grob zu umreißen was sich geändert hat: 2000 kam im 
Consumer-Bereich der erste Pentium 4 auf den Markt. Ich bin mir 
allerdings nicht sicher ob das der damals schnellste erhältliche 
Intel-Prozessor war.

Wenn mehr Rechenleistung für "aufwendige Rechnungen" auf dem Desktop 
benötigte konnte zu Workstations greifen. Je nach Anwendung Feld, Wald 
und Wiesen Workstations wie SPARCultra 5 und 10 mit UltraSPARC IIi CPU 
oder, wenn Chef gönnte, zum Beispiel SGI Octane mit MIPS R10000 (30000 
USD). Natürlich auch alles was von anderen Herstellern dazwischen lag.

Wenn das nicht reichte musste man per Fernzugang ins Rechenzentrum. Die 
nächste Eskalationsstufe danach waren Supercomputer. Beides für 
Privatleute damals völlig unmöglich.

Alles Schnee von Gestern.

Heute hat ein Handy die Rechenleistung damaliger Supercomputer. 
"aufwendige Rechnungen" von vor der Jahrtausendwende kaut dir heutzutage 
ein Office-PC durch ohne warm zu werden. Von PCs mit aktuellem Intel- 
oder AMD-Spitzenprodukt gar nicht zu reden. Was ist das momentan? 
i9-14900KS?

GPUs als nächste Eskalationsstufe wurden schon erwähnt. Wenn das nicht 
reicht oder du nicht GPUs programmieren möchtest, dann kannst du 
heutzutage auch als Privatmann ins Rechenzentrum gehen. Das nennt sich 
heute nur Cloud und Anbieter wie Amazon oder Google verkaufen dir CPU 
(und GPU) Rechenzeit zu erträglichen Preisen.

Beitrag #7754662 wurde vom Autor gelöscht.
von Jens G. (jensig)


Lesenswert?

Hannes J. schrieb:
> GPUs als nächste Eskalationsstufe wurden schon erwähnt.

Als Programmiersprache, nach der hier ja gefragt wurde, ist die aber 
ganz schön komisch ...

von Stephan S. (uxdx)


Lesenswert?

Python ist in der Wissenschaft weit verbreitet, weil es eine 
Skriptsprache ist, die einfach und übersichtlich ist und man die 
Programme leicht ändern kann. Zudem bietet sie zahlreiche fertige 
Bibliotheken, z.B. das o.g. numpy https://de.wikipedia.org/wiki/NumPy 
und scipy https://de.wikipedia.org/wiki/SciPy

: Bearbeitet durch User
von M.A. S. (mse2)


Lesenswert?

Jens G. schrieb:
> Hannes J. schrieb:
>> GPUs als nächste Eskalationsstufe wurden schon erwähnt.
>
> Als Programmiersprache, nach der hier ja gefragt wurde, ist die aber
> ganz schön komisch ...
Das stimmt.
Aber der TO hat angegeben, dass er sich in diesem Jahrtausend noch nicht 
mit der Thematik beschäftigt hat und da ist ein entsprechender Hinweis 
(auch wenn er keine Programmiersprache benennt) sicher nicht verkehrt.

von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?


von Thomas W. (dbstw)


Lesenswert?

Es stellt sich natuerlich die Frage, ob sich das Problem parallelisieren 
oder nicht. Lasst es sich parallelisieren, ist natuerlich in den letzten 
zwanzig Jahren eine Unmenge passiert.

Zum einen ist die Hardware billig und portabel geworden (ich habe hier 
einen Consumer-PC mit 6 Kernen, im Jahr 2000 waere noch richtig teuer 
gewesen), zum andern hat z.B. Fortran 2023 (ISO/IEC 1539:2023) massives 
parallel Rechnen vereinfacht (z.B. die Matrix-Rechnungen).

von (prx) A. K. (prx)


Lesenswert?

Bestens geeignet für Abbildung mathematischer Verfahren im Programm 
sollte ja wohl APL sein. Weshalb sich manche bereits Gedanken gemacht 
haben, APL auf GPUs zu implementieren. Die Sprache bietet reichlich 
Gelegenheit, Parallelität auszudrücken und GPUs sind genau dafür 
geschaffen.

https://elsman.com/pdf/Dyalog17.pdf

: Bearbeitet durch User
von Jan K. (jan_k776)


Lesenswert?

- Fortran
- C & C++
- MATLAB
- Julia
- Python

Für Linear Algebra nutzen eh all die genannten Sprachen die selben 
libraries, LAPACK/BLAS, daher ist das high level Interface gar nicht so 
wichtig.

Für Differentialgleichungen werden häufig SUNDIALS solver benutzt: 
https://computing.llnl.gov/projects/sundials

Auch können alle genannte Sprachen parallelisieren, und auf GPUs 
arbeiten.

IMO ist es nahezu egal, welche high-level Sprache man nutzt, es sei denn 
es geht um Probleme, die hoch individuell sind, und es auf schnelle 
Schleifenausführung oder bedingte Sprünge ankommt, denn da sind 
interpretierte Sprachen traditionell langsamer.

Für "standard" Probleme im Wissenschaftlichen Rechnen würde ich immer 
MATLAB, Julia, oder Python nutzen.

von Pandur S. (jetztnicht)


Lesenswert?

Eine Programmiersprache kann gar nichts. Die machen alle dasselbe, mehr 
oder weniger. Die Geschwindigkeit macht man mit den Algorithmen. Ja, man 
kann spezielle Mathematik Libraries verwenden, muss aber trotzdem eine 
Ahnung haben. Das Geheimnis an Simulation ist das unnoetige Wegzulassen.

Der Unterschied der Libraries : Eine Matrixmultiplikation in C/C++ ist 
ein For (x=.. ) for (y=.. ) mit N Quadrat Operationen. Wenn man nun 
weiss, dass die Matrix schmal ist, weil Finite Elemente, sind's nur noch 
N Linear Operationen. Das geht fuer N gegen Gross in die Zeit.

von Rbx (rcx)


Lesenswert?

Fritz G. schrieb:
> Zu meiner Studienzeit war Fortran das Mass
> aller Dinge

Das ist aktuell immer noch so. C und C++ gewissermaßen als "Wingman" 
unterwegs, und Rust ist auch recht potent und wird auch schon 
eingesetzt. Da fehlen dann aber die vertrauten Bibliotheken und 
Parallelisierer oder was auch immer.
Rust könnte schon der neue Maverick werden, fehlt halt ein wenig der 
Unterbau und das Drumherum, was bei C und C++ schon länger vorhanden 
ist.
(https://www.intel.com/content/www/us/en/high-performance-computing/hpc-software-and-programming.html)

von Giovanni (sqrt_minus_eins)


Lesenswert?

Die Frage war nach Programmiersprachen für numerische Berechnungen:

Hier ein Artikel (frei verfügbar) aus Sicht der Wissenschaft - auch mit 
Vergleichen der schon genannten Sprachen.

https://link.springer.com/article/10.1007/s41781-023-00104-x

Die Frage ist nicht immer die Geschwindigkeit in der Ausführung, sondern 
auch die Zeit die ich zum Erstellen des Programms brauche, die 
Wiederverwendbarkeit und die Sicherheit (hier dürfte RUST aktuell das 
Rennen machen).

In der Ausführung zählt nicht nur die Zeit für die numerische 
Bearbeitung, sondern auch die Zeit für die Speicherverwaltung (garbage 
collection).

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Rbx schrieb:
> Fritz G. schrieb:
>> Zu meiner Studienzeit war Fortran das Mass
>> aller Dinge
>
> Das ist aktuell immer noch so. C und C++ gewissermaßen als "Wingman"
> unterwegs, und Rust ist auch recht potent und wird auch schon
> eingesetzt. Da fehlen dann aber die vertrauten Bibliotheken und
> Parallelisierer oder was auch immer.
> Rust könnte schon der neue Maverick werden, fehlt halt ein wenig der
> Unterbau und das Drumherum, was bei C und C++ schon länger vorhanden
> ist.
> 
(https://www.intel.com/content/www/us/en/high-performance-computing/hpc-software-and-programming.html)

Ich würde sagen, bei C/C++ Vs Fortran ist es hauptsächlich der Compiler, 
der den Unterschied heute macht (klammert man die Algorithmen an sich 
aus).

Da ist es oft sinnvoll GCC, llvm und z.b den Intel Compiler zu 
vergleichen.

Die können ein optimiertes complilat für die ziel-cpu erstellen... Das 
hat einen weitaus größeren Impact als die Sprache.

Wobei natürlich eigen3 in C++ ein weitaus besseres optimieren über die 
gesamte Applikation erlaubt, als z.B irgend ein Python Script.... Ich 
meine damit aber jetzt nicht high Level optimization, sondern Dinge wie 
Link-Time-Optimization und co, die vom Compiler/linker durchgeführt 
werden.

Der Zeitunterschied beim coden ist IMHO nicht existent bzw 
vernachlässigbar, wenn man sich die eigentliche Entwicklungszeit der 
eigentlichen Algorithmen mit "Bleistift/Papier" ansieht.

Daher mein Tipp: zuerst gut überlegen und dann in einer Compiler Sprache 
die man wirklich versteht schreiben. Libs sind gut, aber man muss auch 
dort verstehen wie sie arbeiten um die Daten effizient bearbeiten zu 
können.

Umkopieren und im Extremfall typ-konvergieren bei der Übergabe von lib A 
nach lib B kann einem den Tag versauen.

Bei mir ist es C++ im Qt Framework (GUI, ii,...) gespickt mit eigen3 und 
boost für Numerik, optimization,...

Was mich zur Frage vom TO bringt: was nehmen die im Cluster

Tja die nehmen das, was sie gut verstehen und am Cluster supported wird.

Soweit ich informiert bin, ist der GCC am ARM das Maß aller Dinge. Am 
x86 LLVM oder der Intel Compiler.

Dann stellt sich die Frage, wie die interconnects bedient werden.
OpenMP ist z.B beim GCC quasi ein Compiler Flag. Es gibt da aber viele 
lösungen für unterschiedlichste workloads und Cluster Architekturen.
Dazu kommen dann so Dinge wie CUDA, OpenCL,...

Und erst jetzt wird die Sprache, in der "die paar Zeilen Algorithmus" 
implementiert werden, interessant.

Rust hat ein paar recht interessante Eigenschaften, die zumindest 
theoretisch dem Compiler Möglichkeiten für ein noch aggressiveres 
optimieren geben (also weniger "Tricks" als in C/C++ erlauben) sollten.

Ob sich das im Vergleich zu Fortran oder C/C++ tatsächlich auswirkt... 
Schwer abzuschätzen. Irgendwann fängt man immer an, den profiler 
anzuwerfen. Im Extremfall wird dann eine Funktion per Hand optimiert 
oder aber ein Datenfluss komplett umgestellt. Das hat für mich dann aber 
wieder weniger mit der Wahl der Sprache zu tun.

73

von Sarah D. (sarahcherie)


Lesenswert?

Ganz klar Ada. Wird gerne in der Luft- und Raumfahrt genutzt für 
numerische Berechnungen. 
https://de.wikipedia.org/wiki/Ada_(Programmiersprache)
Ada erlaubt es eigene primitive Datentypen mit vorgegebener Präzision zu 
definieren.

von Oliver S. (oliverso)


Lesenswert?

Sarah D. schrieb:
> Ganz klar Ada. Wird gerne in der Luft- und Raumfahrt genutzt für
> numerische Berechnungen.

Ganz klar COBOL. Wird überall gerne in der Wirtschaft genutzt für 
numerische Berechnungen.


Die genaue Bedeutung von „gerne“ in diesem Kontext ist allerdings nicht 
die, die im Duden steht.

Oliver

Beitrag #7761080 wurde von einem Moderator gelöscht.
Beitrag #7761086 wurde von einem Moderator gelöscht.
Beitrag #7761094 wurde von einem Moderator gelöscht.
Beitrag #7761099 wurde von einem Moderator gelöscht.
von M.A. S. (mse2)


Lesenswert?

Oliver S. schrieb:
> Ganz klar COBOL. Wird überall gerne in der Wirtschaft genutzt für
> numerische Berechnungen.
>
> Die genaue Bedeutung von „gerne“ in diesem Kontext ist allerdings nicht
> die, die im Duden steht.
:D

Ein ehemaliger Schulkamerad von mir, der dann Informatik studiert hat, 
nahm nach dem Abi eine Job an, bei dem er in COBOL programmierte.
Das hat ihm, glaub ich, nicht wirklich Spaß gemacht. Sein Kommentar:
"Man zwingt mich. Mit Geld."
:)

: Bearbeitet durch User
von Ein T. (ein_typ)


Lesenswert?

Giovanni schrieb:
> Die Frage ist nicht immer die Geschwindigkeit in der Ausführung, sondern
> auch die Zeit die ich zum Erstellen des Programms brauche, die
> Wiederverwendbarkeit und die Sicherheit (hier dürfte RUST aktuell das
> Rennen machen).

Das ist zwar korrekt, allerdings sehe ich nicht, daß die Sicherheit, die 
Rust bieten kann, für akademische Anwendungen oder 
High-Performance-Computing eine prominente Rolle spielen würde. Die 
Anwender in diesem Umfeld haben auch wenig Interesse, sich mit Dingen 
wie Speicherverwaltung, Ownership und Typsicherheit herumzuschlagen -- 
das siehst Du bereits daran, daß die beliebteste Spache in diesem 
Bereich aktuell Python ist. Das erledigt alle diese Dinge ohne manuelle 
Eingriffe, wenn auch zum Preis eines etwas höheren Ressourcenbedarfs und 
einer etwas weniger hohen Performance. Stattdessen spielt Python in 
diesem Umfeld seine großen Stärken aus, insbesondere Zugänglichkeit und 
Übersichtlichkeit, seine exorbitante Infrastruktur, sowie seine einfache 
Verwendung als "Glue-Sprache" bei der Nutzung von Code aus anderen 
Sprachen.

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Ein T. schrieb:
> daß die beliebteste Spache in diesem
> Bereich aktuell Python ist

Fritz G. schrieb:
> Was würde man heute nehmen, wenn man eine klassische "number
> crunching"-Anwendung neu schreiben würde?

Fritz G. schrieb:
> Software mit hohem numerischen
> Rechenaufwand, beispielsweise Wetter- und Klimasimulationen oder
> Quantenchemie

Ich glaube, da muss man deutlich differenzieren!

Python ist absolut ungeeignet typische numerische Probleme "direkt" zu 
lösen.

Ja, es gibt viele, die das quasi als moderneres Matlab verwenden (auch 
darin kann man Anwendungen machen und das wurde auch gerne gemacht, wenn 
man die numerischen libs gebraucht hat).

Das, von dem der TO gesprochen hat, wird aber verteilt über mehrere 
Systeme mit diversen Beschleunigern gemacht.

Da spielt die Zeit für's "schreiben" der Anwendung udgl. praktisch keine 
Rolle!

Ja, wenn du alles in einer Maschine hast, dann kann das mit Python und 
den vorhandenen libs (die dann aber in C/C++, Fortran, "OpenCL" oder 
"CUDA" geschrieben wurden) schon funktionieren.

Im Cluster, behaupte ich, schaut die Welt anders aus.

Wenn ich infiniband interconnts im Cluster bezahlen würde, dann wär 
jeder der ohne Grund Python nimmt sofort auf der Straße. Wobei hier 
Python durch jede x-beliebige Sprache ersetzbar ist!

In dem Bereich ist Hardware so teuer, dass sich noch jedes zusätzliche 
Mannjahr Arbeit auszahlen kann.

Man beachte hier "kann".

Was ich damit meine sah/sieht man bei den crypto mining rigs mir 
Grafikkarten schön. Da gab/gibt es Karten mit fetten GPS aber nur pci-e 
3.0 x1 links.
Auf dem Board, das 8 dieser karten fasst, werkelt dann daneben irgend 
eine (verglichsweise) "low-cost-cpu"

Das wären dann Workloads, wo wahrscheinlich sogar javascript ohne JIT 
compiler schnell genug wäre die Karten zu fütten, weil dort tatsächlich 
der allergrößte teil der Arbeit über irgendeinen OpenCL/CUDA/... Kernel 
erledig wird und alles rundherum eigentlich 2. rangig bei der gesamt 
performance ist.

Dort kann man auch recht problemlos den "cluster" über einen normalen 
Internet uplink verbinden und ihn dann mining-pool nennen.

Hast du aber ein IO-lastiges Problem, dann willst du jeden unnötigen CPU 
taktzyklus vermeiden.

Und gerade das macht Rust nun wieder interessant.

Je mehr Annahmen ein Compiler treffen kann, desto mehr 
Optimierungsmöglichkeiten hat er.
Der gcc hat z.B. dieses Flag: "-fopt-info". Damit kannst du dir ansehen, 
wo er warum nicht optimieren konnte. Mit den "restriktionen" von Rust 
sind einfach gewisse Probleme, die ein Optimieren verhindern, nicht 
möglich.

Aktuell scheint C++ in benchmarks noch etwas schneller als Rust zu sein.
Ich behaupte aber, dass die von Rust geforderte Disziplin das 
Durchschnittsprogramm schneller als eines in C++ machen sollte.

Nicht jeder kennt den verwendeten compiler für seine zielarchitektur so 
genau, dass er genau die richtigen design-pattern anwendet...

Nichtsdestotrotz werde ich auf absehbare Zeit hauptsächlich bei C++ 
bleiben.
Insbesondere wenn der code schnell sein soll, habe ich dort einfach 
(noch) wesentlich mehr Erfahrung.

Fritz G. schrieb:
> C(++) ist zwar weit
> verbreitet, aber für numerische Rechnung (z.B. lineare Algebra) eher
> umständlich. Ist Python eine Alternative?

Zum Schluss noch eine Anmerkung, weil da sicher wieder ein "aber python 
hat doch..." kommt.

Eigen3 (in C++) ist eine header-only lib, die wirklich schnell 
(schneller als freie BLAS implementierungen!) und (in meinen Augen) 
extrem konfortable ist.

Python gefällt mir sprachlich überhaupt nicht... aber ich nutze z.B Deno 
sehr gerne. Das hat auch numpy bindings.

Wenn ich jetzt ein Problem habe, bei dem ich direkt in C++ schnell zum 
Ziel komme weil mir da vllt. Qt in die Hände spielt, dann macht man es 
da.

Ist es aber bequemer mit Deno an die Daten ranzukommen und das Ergebnis 
lässt sich so hinreichend schnell berechnen (man muss dazu sagen, dass 
über den V8 JIT auch Deno Code richtig schnell sein kann!), dann wird 
das so gemacht.

Habe ich aber Gründe, in denen ich nichtmal std::vector nehmen will, 
weil ich z.B auf die CPU cachline größe achtgeben darf, dann nehme ich 
hardcode-no-lib-c++.

Was ich sagen will: Das eigentliche Problem diktiert die Sprach-Wahl. 
Nicht die verfügbaren Libs (es gibt so ziemlich jede schnelle Lib in 
jeder sprache) oder die zeit, die man für's schreiben braucht oder 
ähnliches.

Kleines Beispiel.
Sagen wir wir hätten ein Problem bei dem die a2-megagpu-16g bei google 
compute engine eine Woche rechnet.

Kostet aktuell lt. Homepage $60.9/h on demand.
Macht gut 10k pro Woche.

Sagenwir dein "Coder" kostet dir 120€/h (damit 1k pro tag rauskommt).
Ob der jetzt 1 oder 2 tage arbeitet macht nicht einmal 10% bei den 
Kosten aus.

Nachdem das Thema HPC aber doch ziemlich divers ist, lässt sich diese 
Aussage natürlich auch auf den Kopf stellen... womit "Das eigentliche 
Problem diktiert die Sprach-Wahl." noch einmal bewiesen wäre!

73

von Rbx (rcx)


Lesenswert?

Hans W. schrieb:
> womit "Das eigentliche
> Problem diktiert die Sprach-Wahl." noch einmal bewiesen wäre!

Die "Lesenswert"-Einstufung finde ich, kann man hier direkt wörtlich 
nehmen.
Ich hatte vor einigen Jahren mal eine Frage hier gestellt, die drehte 
sich in etwa um Optimierungen, Asm, Sprachen, Diskussionen.
Da kamen dann über 200 Antworten, und nicht nur das, jede für sich 
einzigartig und hochinteressant, also sehr wenig Redundanz.
Diese vielen hochkarätigen Beiträge unterstreichen letztendlich genau 
das was du hier schreibst.

Es gibt ein schönes Rust-Programm, welches ein wenig POC ist, aber auch 
zeigt, wie weit man mit Rust kommen kann, wenn man sich etwas Mühe gibt:
https://github.com/BurntSushi/ripgrep

Wetterberechnungen, und das kam hier noch gar nicht zu Sprache, brauchen 
auch sowas wie  MPI (Message Passing Interface)
https://de.wikipedia.org/wiki/Message_Passing_Interface
wo C++ mit seiner Objekt-Orientierung gewisse Vorteile hat.
Naja und Haskell:
https://hackage.haskell.org/package/haskell-mpi/docs/Control-Parallel-MPI-Fast.html
(;)
(typisch Haskell eben)
Ein anderer problematischer Hintergrund ist die objektive Daten 
Interpretation.
Und da sind wir dann schon mit einem Bein im politischen, da wollen wir 
gar nicht hin.
Es wäre aber schön, wenn die Hintergründe, Handgriffe und 
Interpretationshilfen der üblichen Statistik-Nutzung einigermaßen 
bekannt sind.

Beitrag #7761448 wurde von einem Moderator gelöscht.
von Wolfgang B. (wolfgangkarl) Flattr this


Lesenswert?

Hallo in die Runde,
meiner Meinung nach, je nach was man machen will, ist Python die erste 
Wahl um zu experimentieren. Wenn der Python-Funktionsumfang ausreichend 
ist, dann kann man Cython nehmen, C-Code generieren und dann für die 
verwendete Platform kompilieren. Dadurch wird die Geschwindigkeit 
wesentlich verbessert. Eine sehr gute Alternative ist die 
Programmiersprache Julia. Diese Programmiersprache wurde genau für
numerisches und wissenschaftliches Rechnen entwickelt. Diese 
Programmiersprache ist Open-Source.

von Ein T. (ein_typ)


Lesenswert?

Hallo Hans,

lieben Dank für Deine langen Texte. Bitte verzeih', daß ich nicht auf 
jeden Punkt einzeln eingehen kann.

Hans W. schrieb:
> Ich glaube, da muss man deutlich differenzieren!

Das glaube ich auch.

> Das, von dem der TO gesprochen hat, wird aber verteilt über mehrere

Genau hier geht die Differenzierung schon los.

Dein Beispiel des Cryptomining gefällt mir für das eine Extrem sehr gut: 
da werden seit Jahren immer wieder dieselben Algorithmen gerechnet, und 
am Ende hängt das Einzig Wichtige (tm) dabei am Verhältnis zwischen den 
Kosten (im Wesentlichen für Hardware und Energie) und dem Ertrag 
(Coins). In solchen Fällen ist es natürlich klug, so effizient wie 
möglich zu rechnen, und eine umfangreiche Optimierung ist daher 
ausgesprochen sinnvoll.

In anderen Fällen wie der Klimaforschung geht es hingegen darum, immer 
wieder mal mehr, mal weniger stark veränderte Modelle zu berechnen, die 
Daten nach den Rechenschritten immer wieder anders zu korrigieren, und 
dabei spielen die Entwicklungsaufwände und -Zeiten in seriösen 
Kalkulationen und Beurteilungen dann schon wieder eine gänzlich andere 
Rolle. Denn, übertrieben gesagt: noch schlimmer als ein langsamer 
Cluster ist einer, der gar nichts rechnet, weil die Entwickler noch in 
ihrer nächsten Iteration feststecken. ;-)

> Ja, wenn du alles in einer Maschine hast, dann kann das mit Python und
> den vorhandenen libs (die dann aber in C/C++, Fortran, "OpenCL" oder
> "CUDA" geschrieben wurden) schon funktionieren.
>
> Im Cluster, behaupte ich, schaut die Welt anders aus.

Das stimmt, aber nichts -- ich wiederhole: nichts! -- hindert Python 
daran, vorhandene Clusterarchitekturen zu benutzen, seien es 
Infrastrukturen zum Batchprocessing wie Apache Spark (PySpark!) oder 
Stream Processing Engines wie Apache Storm, Heron, oder Gearpump. MPI 
for Python [1] existiert, und es gibt sogar einen speziellen 
Just-in-time-Compiler für numerische Applikationen numba [2], dessen 
Ausführungsgeschwindigkeit häufig durchaus mit Fortran und C/Cpp 
mithalten kann. Schnittstellen zu CUDA, Vector und  gibt es ebenso wie 
auf Python spezialisierte Distributed-Computing-Frameworks wie Ray.

Naja, ich will hier nicht die ganze Landschaft der in Python oder für 
Python entwickelten Werkzeuge ausbreiten, das würde den meine zeitlichen 
Ressourcen und vermutlich auch den Rahmen dieses Forums sprengen. 
Tatsache ist aktuell, daß Python heute eine der, wenn nicht gar die 
verbreitetste Sprache ist, und das betrifft eben auch rechenintensive 
Bereiche wie Distributed Computing, Maschine Learning und Artificial 
Intelligence.

[1] https://mpi4py.readthedocs.io/en/stable/
[2] https://numba.pydata.org/
[3] https://www.ray.io/

> Wenn ich infiniband interconnts im Cluster bezahlen würde, dann wär
> jeder der ohne Grund Python nimmt sofort auf der Straße. Wobei hier
> Python durch jede x-beliebige Sprache ersetzbar ist!

Allerdings gibt es nichts, das Python daran hindern würde, Interconnects 
mit Infiniband oder [1248]00GBASE-X zu benutzen...

> In dem Bereich ist Hardware so teuer, dass sich noch jedes zusätzliche
> Mannjahr Arbeit auszahlen kann.

Im Moment sehe ich eher ein Auseinanderdriften zweier Ansätze. Die 
riesigen, teuren Maschinen wie früher die E10k, um ein prominentes 
Beispiele zu nennen, verschwinden zunehmend in Nischen, in denen es aus 
welchen Gründen auch immer notwendig ist, sehr große Workloads auf einer 
Maschine zu verarbeiten. In der breiteren Anwendung sehe ich heute 
etliche große COTS-Cluster (Common Of The Shelf), deren Maschinen im 
Prinzip aus billiger Consumer-Hardware bestehen und je nach 
Anwendungsfall mit spezieller Hardware zum Beispiel für Interconnect und 
GPU-Computing nachgerüstet werden. Sehr häufig kosten die Nachrüstungen 
dabei sogar wesentlich mehr als der Rechner, in dem sie stecken.

> Das wären dann Workloads, wo wahrscheinlich sogar javascript ohne JIT
> compiler schnell genug wäre die Karten zu fütten, weil dort tatsächlich
> der allergrößte teil der Arbeit über irgendeinen OpenCL/CUDA/... Kernel
> erledig wird und alles rundherum eigentlich 2. rangig bei der gesamt
> performance ist.

Absolut richtig, nur daß Python im Gegensatz zu Javascript ausdrücklich 
mit (unter anderem) Ziel entwickelt wurde, eine Glue-Sprache zu sein. 
Und genau diese Eigenschaft ist es, warum es so viele in anderen 
Sprachen entwickelte Libraries und Frameworks für Python gibt, warum die 
Boost-Entwickler eigens Boost.Python zur Einbindung von Python in C++ 
und C++ in Python entwickelt haben, warum im Bereich der KI die 
verbreitetsten Frameworks, Tensorflow und PyTorch, auf Python 
ausgerichtet sind.

All dies trägt dazu bei, daß Python auch im Bereich des High Performance 
Computing so beliebt und verbreitet ist: es bietet einen einfachen 
Zugang zu hoher Rechenleistung und verteiltem Rechnen, ist leicht les- 
und schreibbar, hat eine enorme Infrastruktur, und es funktioniert 
wunderbar als Glue-Code zwischen vielen, bisweilen sehr verschiedenen 
Domänen.

> Hast du aber ein IO-lastiges Problem, dann willst du jeden unnötigen CPU
> taktzyklus vermeiden.

Wir scheinen, wie sage ich das... sehr unterschiedliche Ansätze zu 
verfolgen, denn wenn ich ein IO-lastiges Problem habe, dann kümmere ich 
mich zuerst um meinen I/O. Um die CPU-Taktzyklen kümmere ich mich nur, 
wenn mein Problem ein CPU-lastiges ist. Du hast Dich verschrieben, oder? 
;-)

> Aktuell scheint C++ in benchmarks noch etwas schneller als Rust zu sein.
> Ich behaupte aber, dass die von Rust geforderte Disziplin das
> Durchschnittsprogramm schneller als eines in C++ machen sollte.

Naja... Rechnen müssen sie am Ende doch alle, und selbst mit 
größtmöglicher Optimierung kosten Berechnungen nun einmal Taktzyklen. 
Für ein paar Prozent höherer Rechenleistung von einer etablierten 
Sprache mit etlichen fertigen Libraries und Frameworks auf eine andere 
Sprache zu wechseln und dafür dann womöglich signifikante Teile einer 
Applikation neu schreiben und natürlich danach auch pflegen und warten 
zu müssen, ist eine eher selten getroffene Entscheidung, die vermutlich 
nur in wenigen Ausnahmefällen ökonomisch ist. Bisher sehe ich noch 
nicht, daß Rusts Infrastruktur an jene herankommt, die für C++ und 
Python bereits existieren. Aber warten wir ab, bekanntlich ist 
schließlich nichts so beständig wie der Wandel.

> Nichtsdestotrotz werde ich auf absehbare Zeit hauptsächlich bei C++
> bleiben.
> Insbesondere wenn der code schnell sein soll, habe ich dort einfach
> (noch) wesentlich mehr Erfahrung.
> [...]
> Python gefällt mir sprachlich überhaupt nicht...

Jaaa... weißt Du, für mich ist Python nur ein Werkzeug im Köcher, das 
sehr viele Anwendungsfälle mit guter bis ausreichender Performance löst. 
Wenn ich mehr Rechenleistung brauche, schreibe ich meine Software 
entweder in C++ oder als C++-Erweiterung für Python, in einigen Fällen 
greife ich auch zu Golang und in anderen auch mal zu Java- bzw. 
ECMAScript.

Aber bei der Lektüre Deiner Ausführungen merke zumindest ich sehr 
deutlich, daß Du Python nicht magst, und Dich (vermutlich deswegen) auch 
noch nie so intensiv damit beschäftigt hast, als das Du wüßtest, was 
Pythons Tooling und Infrastruktur zu bieten haben. Das ist nicht 
schlimm, reicht IMHO aber auch nicht aus, um Dir ein realistisches 
Urteil zu bilden.

> Wenn ich jetzt ein Problem habe, bei dem ich direkt in C++ schnell zum
> Ziel komme weil mir da vllt. Qt in die Hände spielt, dann macht man es
> da.

Nicht "man", Du. Andere Entwickler nutzen andere Technologien, manche 
Python, andere Golang, noch andere C, C++, Julia, Erlang, Haskell, 
Clojure oder Julia, und wieder andere nehmen halt Rust. Finde ich gut, 
denn das Ergebnis dessen ist, daß dessen Teilnehmer in einem Wettbewerb 
und so unter einem gewissen Druck stehen, ihre Lösungen kontinuierlich 
zu erweitern und zu verbessern -- und genau deswegen können wir als 
Entwickler heute (meistens) frei wählen, welche Sprache, welche 
Frameworks und welche Libraries wir nutzen wollen.

: Bearbeitet durch User
von Frank O. (frank_o)


Lesenswert?

Ist doch immer geil, wenn der TO nach dem Eröffungspost völlig 
verschwunden ist.
Da könnte der TO doch schreiben, dass sich das Problem erledigt hat oder 
er schon hier oder dazu tendiert.

Aber ansonsten fand ich die Diskussion interessant.

Beitrag #7762016 wurde von einem Moderator gelöscht.
von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

Fritz G. schrieb:
> Quantenchemie,

Im Hintergrund, ohne echten Quantencomputer, werden Module zur 
Simulation des Quantenrechners in Assembler geschrieben, wegen der . Das 
wirst Du aber nie machen oder reinschauen, weil dank API, Bibliotheken.

Wenn grosse festgelegte Matrizen im Speicher gehalten werden mit 
entsprechenden Matrixoperationen, gibt es dafuer fertige 
ASM-Bibliotheken.

Wobei wichtig dabei ist zu wissen, das der Compiler in C-geschrieben 
ist, der das in Maschinenbefehle umsetzt.

Das ist sehr speziell und braucht der TO sicher nicht.

: Bearbeitet durch User
von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Ein T. schrieb:
>> Hast du aber ein IO-lastiges Problem, dann willst du jeden unnötigen CPU
>> taktzyklus vermeiden.
>
> Wir scheinen, wie sage ich das... sehr unterschiedliche Ansätze zu
> verfolgen, denn wenn ich ein IO-lastiges Problem habe, dann kümmere ich
> mich zuerst um meinen I/O. Um die CPU-Taktzyklen kümmere ich mich nur,
> wenn mein Problem ein CPU-lastiges ist. Du hast Dich verschrieben, oder?
> ;-)

Nein. I/O lastig bedeutet (vereinfacht), es müssen möglichst oft mit 
möglichst wenig Taktzyklen möglichst viele Bytes von der Quelle zur 
Senke bekommen... im Idealfall 0, weil alles per DMA über den memory 
controller mit maximaler Bandbreite läuft.


Aber du musst diese Aussage auch im Kontext sehen!

Hans W. schrieb:
> Dort kann man auch recht problemlos den "cluster" über einen normalen
> Internet uplink verbinden und ihn dann mining-pool nennen.
>
> Hast du aber ein IO-lastiges Problem, dann willst du jeden unnötigen CPU
> taktzyklus vermeiden.
>
> Und gerade das macht Rust nun wieder interessant.

Und hier dann weiter lesen...

Ein T. schrieb:
>> Aktuell scheint C++ in benchmarks noch etwas schneller als Rust zu sein.
>> Ich behaupte aber, dass die von Rust geforderte Disziplin das
>> Durchschnittsprogramm schneller als eines in C++ machen sollte.
>
> Naja... Rechnen müssen sie am Ende doch alle, und selbst mit
> größtmöglicher Optimierung kosten Berechnungen nun einmal Taktzyklen.
> Für ein paar Prozent höherer Rechenleistung von einer etablierten
> Sprache mit etlichen fertigen Libraries und Frameworks auf eine andere
> Sprache zu wechseln und dafür dann womöglich signifikante Teile einer
> Applikation neu schreiben ....

Meine Aussage war hier nur, dass Rust gewisse Eigenschaften besitzt, die 
mMn automatisch zu einem disziplinierten Programmieren führen und 
dadurch zu (im Schnitt) effizienteren Programmen.

Meiner Erfahrung nach sind alle Optimierungs-"Hacks" am Ende 
kontraproduktiv, weil sie "global" (zu lesen: im Kontext der gesamten 
Applikation) betrachtet zu semioptimalen Lösungen führen.

z.B lustige Pointer-Casts mit komplizieren Array zugriffen und dann 
brutalen Typumwandlungen meine ich damit.

Das passt dann entweder nur gut für 1nen speziellen Anwendungsfall oder 
führt dann zu Aussagen wie "Der Datenfluss schaut an der Stelle so 
'seltsam' aus, weil er historisch gewachsen ist".

Meiner Einschätzung nach hilft dagegen nur Disziplin.
Wenn die stimmt, sind meistens (Achtung: MEISTENS!) die Optimizer so 
gut, dass sie insgesamt mehr Performance rausholen wie jeder "Hack". Die 
Sprache ist da meist ziemlich egal.

Nirgends stand da was von neu schreiben, libs weglassen udgl.!

Ich habe auch kein "Rust rulez!!!11!!" abgelassen!

Dinge wie die strenge Typisierung oder den borrow checker meinte ich.
So etwas in einer Sprache durchzuziehen kann dem Optimizer massiv 
helfen.
Und das finde ich interessant... nicht mehr, und nicht weniger!

Ein T. schrieb:
> Aber bei der Lektüre Deiner Ausführungen merke zumindest ich sehr
> deutlich, daß Du Python nicht magst, und Dich (vermutlich deswegen) auch
> noch nie so intensiv damit beschäftigt hast, als das Du wüßtest, was
> Pythons Tooling und Infrastruktur zu bieten haben. Das ist nicht
> schlimm, reicht IMHO aber auch nicht aus, um Dir ein realistisches
> Urteil zu bilden....

Oh, ich glaube, ich habe durchaus genug Erfahrung in Python um mir ein 
Urteil zu bilden...

Aber um das geht es mir aber nicht!
Mir gefällt die Sprache nicht. Punkt!

Habe ich auch deutlich geschrieben:

Ein T. schrieb:
>> Python gefällt mir sprachlich überhaupt nicht...

Was nutzt mir Infrastruktur und Tooling, wenn ich sie nicht als elegant 
empfinde und mir Grammatik und Syntax auch nicht liegen. Leider ist 
dieses Argument für 99.8% der Python "Verehrer" nicht greifbar.

Ich mag auch Java nicht. Dort gehts mir auch nicht um Swing, Gradle oder 
irgendeiner anderen Komponente in diesem Ökosystem. Ich meine damit die 
Sprache und die Design Pattern, die dort "vorgegeben" werden.

Ein T. schrieb:
>> Wenn ich jetzt ein Problem habe, bei dem ich direkt in C++ schnell zum
>> Ziel komme weil mir da vllt. Qt in die Hände spielt, dann macht man es
>> da.
>
> Nicht "man", Du. Andere Entwickler nutzen andere Technologien

Sorry, Typo... 1 von 4 mal das falsche Pronomen... sorry!

Ein T. schrieb:
> Andere Entwickler nutzen andere Technologien, manche
> Python, andere Golang, noch andere C, C++, Julia, Erlang, Haskell,
> Clojure oder Julia, und wieder andere nehmen halt Rust.

Und warum wirfst du mir dann vor, dass ich Python mir einfach nicht gut 
genug angesehen habe?

Ich weiß nicht, warum die Python Community mit solchen Nachdruck zu 
missionieren  versucht.

Hans W. schrieb:
> Was ich sagen will: Das eigentliche Problem diktiert die Sprach-Wahl.
> Nicht die verfügbaren Libs (es gibt so ziemlich jede schnelle Lib in
> jeder sprache) oder die zeit, die man für's schreiben braucht oder
> ähnliches.

Hier steht's doch!

Nimm das für dein Problem richtige Mittel.

Aber jeder, der ohne überlegen Python (zu ersetzen mit beliebiger 
anderer Sprache/Framework/OS/...) nimmt, fliegt bei mir raus.

Ich denke da auch an die ganzen "excel tools", die mir bei Kunden 
unterkommen.

Absolut nicht zu warten, und wenn man eines geschickt bekommt, ist man 
immer der "Dumme", weil man Excel nicht auf die einzige vernünftige Art 
und Weise konfiguriert hat. Ganz schlimm wirds, wenn man dann sagt, man 
nutze MS Excel gar nicht...

Ein T. schrieb:
> Allerdings gibt es nichts, das Python daran hindern würde, Interconnects
> mit Infiniband oder [1248]00GBASE-X zu benutzen...

Und genau das meinte ich mit

Hans W. schrieb:
> "aber python
> hat doch..."

Wenn du wie du oben sagst, fast so schnellen code in python wie z.B (!) 
in C++ bekommen würdest, egal wie (!), dann ist das eben nur fast so 
schnell.

Ich habe nicht gesagt, dass es nicht ginge, ich habe nur gesagt, dass es 
Fälle gibt, wo eben ein callback vom Kernel in den userspace, in einen 
Python interpreter im Falle von Infiniband Interlinks vllt. nicht die 
optimale Lösung wäre... Klar, wenn du "nur" schnell ein "paar" GB 
austauschen musst... ja mach halt... low-latency IPC...never!

Aber jetzt nochmal um auf den TO (falls er noch mitliest) einzugehen:

Python mag ja recht nett sein... so wie Lua auch nett ist... aber wenn 
die Hauptarbeit dort drinnen "laufen" soll, dann ist das ungeeignet.

Soll heißen, einen iterativen Solver schreibt man damit nicht (auch wenn 
es ginge... kann man auch in Excel).

Das füttern des Selben... wenn _ich's_ danach nicht warten muss... warum 
nicht... gibt ja auch genügend "Manpower" die man sich dazu "einkaufen" 
kann.
Das(!) ist der einzige für mich(!) wirklich relevante Vorteil von 
Python! Es gibt viele Code-Monkeys! Ich bin aber kein Software 
unternehmen, daher ist dieser für mich aber nicht wirklich von 
Bedeutung.

Fortran lebt auch nicht nur wegen Legacy-Code!
Da gibt es extrem hoch optimierte Compiler und es gibt Leute, denen 
gefällt auch diese Sprache sehr gut.

Ich finde gewachsenen Fortran Code auch... hmmm... stark 
gewöhnungsbedürftig.
6 Zeichen Variablen Namen sage ich da nur... aber manchen gefällt sowas.

Grundlegen gilt aber:
Wenn du nicht akademisch arbeitest, dann zählt der Output. Damit meine 
ich nicht die Arbeit, die du verrichtest, sondern das Geld, was am Ende 
des Monats am Firmenkonto übrig bleibt.

Ich habe oben beispielhaft 2 konträre Szenarien beschrieben, bei dem 
1mal der angebliche Zeitvorteil von Python (den ich für mich persönlich 
nicht sehe) schon bei einer Milchmädchenrechnung egal ist.

Beim angedeuteten zweiten Szenario aber eben nicht.

Daher:

Ein T. schrieb:
> Hans W. schrieb:
>> Ich glaube, da muss man deutlich differenzieren!
>
> Das glaube ich auch.

73

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Hans W. schrieb:
> Was nutzt mir Infrastruktur und Tooling, wenn ich sie nicht als elegant
> empfinde und mir Grammatik und Syntax auch nicht liegen.

Kann zuweilen trotzdem wichtiger sein.

Ich mag Git nicht, aber ich benutze es – weil Infrastruktur und Tooling 
drum herum den eigentlichen Mehrwert bringen.

Ich mag auch diese Einrückungs-Verbissenheit von Python nicht, trotzdem 
ist Python aufgrund dessen, was es rundherum gibt oft für mich das 
Mittel der Wahl. Als Interface zu dem (meiner Meinung nach völlig 
undurchdringlichen) Fortran-Code von linpack etc. hilft es mir auf jeden 
Fall, wenn ich ein derartiges Problem lösen muss, und im Gegesatz zu 
Matlab (die auch so ein Interface gebaut haben) kann ich es ohne 
irgendein Lizenzgehampel einfach so benutzen.

von Alexander S. (alesi)


Lesenswert?

Hallo,

wenig bekannt und nicht unbedingt für intensive Rechenanwendungen oder 
hohe Datenmengen:

https://en.wikipedia.org/wiki/Hoc_(programming_language)

https://en.wikipedia.org/wiki/The_Unix_Programming_Environment

http://ftp.math.utah.edu/pub/hoc/

https://neuron.yale.edu/neuron/static/docs/refman/hoc.html

Läuft unter jedem Linux/Unix mit C-Compiler und yacc oder bison Parser.

von Alexander S. (alesi)


Lesenswert?

Jörg W. schrieb:
> und im Gegesatz zu
> Matlab (die auch so ein Interface gebaut haben) kann ich es ohne
> irgendein Lizenzgehampel einfach so benutzen.

Kennst Du den Matlab Clone octave?
https://octave.org/

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Jörg W. schrieb:
> aber ich benutze es – weil Infrastruktur und Tooling
> drum herum den eigentlichen Mehrwert bringen

Ja, damit kann ich gut, und so sehe ich das auch.

Ich nutze Python deshalb auch dort, wo es nicht anders geht (z.B. KiCad 
scripts statt selbst parsen...wobei ich das in 1nem fall auch gemacht 
habe eben um von den KiCad Binaries unabhängig zu sein. )

In anderen Fällen nutze ich Deno.

Das ist für mich
1. angenehmer und
2. bietet es über direkte Bindings, WASM cross-kompilate oder auch der 
NodeJS Kompatibilität für meine web-nahen Anwendungsfälle eigentlich ein 
super simples Framework.

Ich behaupte jetzt einmal, dass sich für web-nahe Probleme python und 
NodeJS/Deno nicht viel unterscheiden.

Einfache Frameworks gibts für beiden. Da ist das wirklich nur eine 
"Geschmackssache" welche der beiden "Frameworks" einem besser liegt.
Genau die Fälle gibt es aber häufiger wie man meinen mag und ich sträube 
mich vehement hier Python zu nutzen... weil mir die Sprache an sich 
nicht gefällt!

Jörg W. schrieb:
> Als Interface zu dem (meiner Meinung nach völlig
> undurchdringlichen) Fortran-Code von linpack etc. hilft es mir auf jeden
> Fall, wenn ich ein derartiges Problem lösen muss

von Linpak, lapak oder gar BLAS bin ich komplett abgekommen.

Eigen3 kann ich da empfehlen, wenn man C++ mag...
Geht aber auch nur, wenn man nicht z.B. auf die Intel MKL angewiesen 
ist.
Schnell ist es auf jedenfall...schneller als die meisten BLAS 
implementierungen.

Ich habe aber extrem selten mit einzelnen Matrix operationen zu tun.
Meistens ist das eine Loop mit Updates von irgendwelchen Vectoren, die 
dann irgendwelche Matrizen "würzen".

min 50% der Zeit geht da für's update der Vektoren drauf... eher 75%...

Sowas in Python????

Ich weiß nicht...

Als Matlab Ersatz... bin dabei! (also im Geiste... für mich reicht der 
gelegentliche Start von Maxima oder Octave).

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Jörg W. schrieb:
> aber ich benutze es – weil Infrastruktur und Tooling
> drum herum den eigentlichen Mehrwert bringen

Ja, damit kann ich gut, und so sehe ich das auch.

Ich nutze Python deshalb auch dort, wo es nicht anders geht (z.B. KiCad 
scripts statt selbst parsen...wobei ich das in 1nem fall auch gemacht 
habe eben um von den KiCad Binaries unabhängig zu sein. )

In anderen Fällen nutze ich Deno.

Das ist für mich
1. angenehmer und
2. bietet es über direkte Bindings, WASM cross-kompilate oder auch der 
NodeJS Kompatibilität für meine web-nahen Anwendungsfälle eigentlich ein 
super simples Framework.

Ich behaupte jetzt einmal, dass sich für web-nahe Probleme python und 
NodeJS/Deno nicht viel unterscheiden.

Einfache Frameworks gibts für beiden. Da ist das wirklich nur eine 
"Geschmackssache" welche der beiden "Frameworks" einem besser liegt.

Genau die Fälle gibt es aber häufiger wie man meinen mag und ich sträube 
mich vehement hier Python zu nutzen... weil mir die Sprache an sich 
nicht gefällt!

Jörg W. schrieb:
> Als Interface zu dem (meiner Meinung nach völlig
> undurchdringlichen) Fortran-Code von linpack etc. hilft es mir auf jeden
> Fall, wenn ich ein derartiges Problem lösen muss

von Linpak, lapak oder gar BLAS bin ich komplett abgekommen.

Eigen3 kann ich da empfehlen, wenn man C++ mag...
Geht aber auch nur, wenn man nicht z.B. auf die Intel MKL angewiesen 
ist.
Schnell ist es auf jedenfall...schneller als die meisten BLAS 
implementierungen.

Ich habe aber extrem selten mit einzelnen Matrix operationen zu tun.
Meistens ist das eine Loop mit Updates von irgendwelchen Vectoren, die 
dann irgendwelche Matrizen "würzen".

min 50% der Zeit geht da für's update der Vektoren drauf... eher 75%...

Sowas in Python????

Ich weiß nicht...

Aber als interatkiver Matlab Ersatz. Da wäre ich dabei!
Also im Geiste... Ich bin da eher bei Maxima oder Octave mit 
entsprechender GUI.

73

von Rbx (rcx)


Lesenswert?

Hans W. schrieb:
> Sowas in Python????

Das Python Problem ist halt: du kannst nicht mal eben den Compiler bzw 
Interpreter umschreiben und "Maschinen-Tunings" gehen halt auch nicht, 
sondern man kann meist nur das nehmen, was schon da ist. Was am Ende 
dazu führt, dass etliche Python Programmierer verzweifelt fragen, wie 
kann ich mein Programm schneller rechnen lassen.

https://www.netlib.org/lapack/lug/node140.html
https://stackoverflow.com/questions/68234466/scipy-blas-lapack-force-use-of-avx-instruction-set
https://discourse.julialang.org/t/about-julias-inline-assembly-usage/30352

Beim  Cell hatte sich ja herausgestellt, dass der enorm von der 
Asm-Programmierung profitiert.

Haskell parallelisiert zwar hervorragend, aber das braucht man 
vielleicht nicht immer und der Asm-Zugang ist da auch nicht mal eben 
abgewickelt.
Und in der Parallel-Rechnung ist Asm eigentlich ziemlich schwierig.

Was will man Leuten erzählen, die meinen, man kann mit Python alles 
machen, schließlich ist Python auch bewährte effektive 
Hackerprogrammiersprache?
Oder was wollte man Mathematikern erzählen, die einfach mal schneller 
rechnen möchten, als das, was die vorhandenen Python-Werkzeuge im 
Angebot haben?

Früher war Basic für vieles gut, es gab auch Interpreter-Code auf 
Heftdisketten, der war recht langsam. Allerdings konnte man Basic auch 
compilieren, nur waren die Compiler nicht immer leicht zu bekommen.
Die Hex und Asm-Ebene nutzen konnte man auch, und so konnte man, wenn 
man wollte, mit Compiler und Asm-Tricks recht schnellen Basic-Code 
hinbekommen.

Basic (oder Pascal) wurde(n) auch noch lange in der Schul-IT eingesetzt

Haskell kann man ganz gut Codetechnisch optimieren. Dadurch kann man 
auch einiges lernen, was bei anderen Programmiersprachen nicht so 
deutlich rüberkommt.
Aber tatsächlich, die Beliebtheit von Python ist auch ein Punkt - nur 
dass der eben eine gewisse Grenze hat.
Performance-Tuning kann man nur per Bib machen, und per Code eher nur, 
wenn man die Möglichkeiten der Code-Optimierungen von Haskell kennt.
Wobei bei Haskell vor allem die Doubles (und nicht die Floats) 
eingesetzt werden sollten, wegen einer besseren Performance.
Die Probleme mit Fließkommazahlen werden dann allerdings nicht behoben.
Fließkommafehler bei Haskell?
http://wiki.haskell.org/Performance/Floating_point
scheinbar nicht bekannt. Ganz anders Python:
https://docs.python.org/3/library/decimal.html

Wird allerdings schwieriger, wenn es um das schneller Rechnen geht. Ich 
denke, die traditionellen Werkzeuge sind nicht umsonst traditionell 
geblieben.
Wegen dem OOP, oder weil es ja auch Java (+ die JVM) gibt könnte man 
Python-Programmierer C++ nahelegen - sofern die gängigen Methoden nicht 
ausreichen.

C++ glänzt ja auch ein wenig als Funktions-Truthahn. Wenn man erstmal 
drin ist, hat man eine ganze Menge Möglichkeiten und ich würde die 
Lernzeit (so 2 Jahre) auch nicht als verschwendet ansehen.

von Mano W. (Firma: ---) (manow)


Lesenswert?

Fritz G. schrieb:
> Welche Programmmiersprache wird heute für Software mit hohem numerischen
> Rechenaufwand, beispielsweise Wetter- und Klimasimulationen oder
> Quantenchemie, verwendet?

Eigentlich wollte ich schreiben guck in die Stellenanzeigen vom DWD. 
Aber guck halt in das Wettermodel vom DWD: ICON. Das gibt es anscheinend 
als OpenSource seit diesem Jahr.

https://icon-model.org

bzw. zum git Repository

https://gitlab.dkrz.de/icon/icon-model

von Rbx (rcx)


Lesenswert?

Mano W. schrieb:
> Aber guck halt in das Wettermodel vom DWD: ICON.

müffelt nach Fortran und C (C wohl u.a. auch für CUDA)
https://fortran-lang.org/en/learn/os_setup/install_gfortran/
https://fortran-lang.org/en/learn/quickstart/hello_world/

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Alexander S. schrieb:
> Jörg W. schrieb:
>> und im Gegesatz zu
>> Matlab (die auch so ein Interface gebaut haben) kann ich es ohne
>> irgendein Lizenzgehampel einfach so benutzen.
>
> Kennst Du den Matlab Clone octave?
> https://octave.org/

Kenne ich, aber Python ist am Ende universeller.

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Rbx schrieb:
> Früher war Basic für vieles gut,

Jörg W. schrieb:
> aber Python ist am Ende universeller.

Das ist glaube ich der Punkt. Leute (da zähle ich mich selber natürlich 
auch dazu!) sind faul und nehmen das was bequem ist.

Das finde ich ist aber oft das Problem.

"Nimm einen AVR"
"Mach in Python"
"Frag ChatGPT"

Das sind für mich vergleichbare allgemeine "Empfehlungen".

Optimal sind solche Empfehlungen oft/meist nicht... Müssen sie oft/meist 
auch nicht.

Ich für mich mag halt Python nicht.
Ich hab für mich aber eigentlich für alle Problemchen gute Lösungen 
gefunden die mir weniger Kopfweh bereiten als diese für mich seltsame 
Sprache.

Aber das ist jetzt wieder OT.

73

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Hans W. schrieb:
> Optimal sind solche Empfehlungen oft/meist nicht... Müssen sie oft/meist
> auch nicht.

So isses.

> Ich für mich mag halt Python nicht.

Ich mag es auch nicht so sehr (und für Textbearbeitung mit regulären 
Ausdrücken greife ich nach wie vor lieber zu Perl), aber habe mich damit 
auch irgendwie arrangieren können – genauso wie halt mit Git.

FORTRAN war anders seltsam :-), aber ich bin froh, dass ich das nicht 
mehr machen muss. Da war ich schon vor über 30 Jahren froh drüber. ;-) 
Die Produktivität stieg mit dem damaligen Pascal-Compiler um ein 
Vielfaches, und zu der Zeit war ich sicher noch unvoreingenommen 
gegenüber FORTRAN.

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Jörg W. schrieb:
> genauso wie halt mit Git

Ich spiele da übrigens mit dem Gedanken wieder zu Mercurial zurück zu 
wandern.

Ich finde persönlich Mercurial "besser".
HgGit erlaubt sogar lokal Mercurial und remote git zu verwenden.

Mir ist git einfach zu "komplex"/"universell". Mercurial beschränkt sich 
gefühlt mit nur 1/10tel der Funkionalität und trifft meine Arbeitsweise 
irgendwie besser.

Bei mir hängt aber mein komplettes Unternehmen daran... Nennen wir es 
jugendlichen Leichtsinn und im Nachhinein gute Entscheidung jedes Kunden 
Projekt in ein gut repo am NAS zu legen (zum verständnis: git ist meine 
Lösung über mehrere Systeme die Projekt Daten konsistent zu halten), 
statt einfach nur eine Verzeichnisstruktur anzulegen.
Aber da unternimmt man so einen Umstieg erst, wenn der Leidensdruck hoch 
ist.

Wobei mich HgGit dazu verleitet, da es transparent wäre. An Server darf 
weiter GitTea laufen und ich bekomme mein Mercurial zurück :)

Problematisch ist aber das Shell Script Set, das meine Arbeit quasi 
fool-proof macht.

Man muss halt dauernd viel neues ausprobieren, sonst landet man im 
"haben wir/ich immer so gemacht"-sumpf. Das erfordert aber wieder die 
Konsequenz zu sagen "lass ich bleiben" oder "bringt mir signifikante 
Vorteile und zieh ich jetzt konsequent durch".
Ansonsten blockiert man sich durch die dauernden veränderungen selbst.

73

von Sheeva P. (sheevaplug)


Lesenswert?

Giovanni schrieb:
> JULIA hat Suchtpotential - erfordert aber ein Umdenken.

Inwiefern?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Hans W. schrieb:
> Ich finde persönlich Mercurial "besser".

Ich auch, aber Mozilla ist beispielsweise von Mercurial zu Git gegangen, 
weil sie mit Mercurial in Performanceprobleme gelaufen sind.

Aber lass uns das bitte in einen eigenen Thread nehmen, wenn du es 
weiter diskutieren möchtest.

Beitrag #7762441 wurde von einem Moderator gelöscht.
von Giovanni (sqrt_minus_eins)


Lesenswert?

Sheeva P. schrieb:
> Giovanni schrieb:
>> JULIA hat Suchtpotential - erfordert aber ein Umdenken.
>
> Inwiefern?

OK, nach Fortran IV, Pascal, Octave, Python jetzt Julia.

Julia setzt auf multiple dispatching - satt object oriented programming. 
Das ist schon mal ganz anders, eröffnet aber viele Möglichkeiten.
Was mich aber beeindruckt hat, ist MetaProgramming. Also Programmteile 
erst zur Laufzeit zu erstellen. Interessant in der Simulationen & ML, wo 
Gleichungen symbolisch differenziert werden müssen.
siehe : https://github.com/sciml

Auch Julia verwendet die Standards wie BLAS, LAPACK, ..., hat 
Schnittstellen zu allen bekannten Solvern und auch zu Python 
Bibliotheken wie MATPLOTLIB.

MetaProgramming macht das Ganze für mich so spannend.

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Jörg W. schrieb:
> Hans W. schrieb:
>> Ich finde persönlich Mercurial "besser".
>
> Ich auch, aber Mozilla ist beispielsweise von Mercurial zu Git gegangen,
> weil sie mit Mercurial in Performanceprobleme gelaufen sind.
>
> Aber lass uns das bitte in einen eigenen Thread nehmen, wenn du es
> weiter diskutieren möchtest.

Weniger OT wie man meinen würde.

https://wiki.mercurial-scm.org/OxidationPlan

Mit zahlen hinterlegt ist auch einiges hier drin zu finden: 
https://mercurial.paris/download/Rust%20in%20Mercurial%20in%202023.pdf

Da steht ziemlich genau warum sie mit Python unzufrieden sind, was sie 
schon alles probiert haben, und wo die Reise hin gehen könnte.

Ist imho lesenswert, weil da auch viel Hintergrundwissen drinnen steht

73

: Bearbeitet durch User
von Rbx (rcx)


Lesenswert?

Sheeva P. schrieb:
> Giovanni schrieb:
>> JULIA hat Suchtpotential - erfordert aber ein Umdenken.
>
> Inwiefern?

Fragst du jetzt nach dem Suchtpotential, oder dem Umdenken?

Ich habe den Verdacht, Worte bringen hier nicht viel. Ich kann mir zwar 
ein paar Eckpunkte denken - aber ich verstehe, so meine ich, in etwa 
schon den Spaßfaktor allein vom Durchlesen der Doku.
Außerdem kann Julia von Haus aus plotten und Haskell eben nicht, ein 
nicht zu verachtender Vorteil, finde ich.
(der übrigens auch für Python spricht)

Jörg W. schrieb:
> FORTRAN war anders seltsam :-)

Fortran war der große Bruder von Basic. Oder umgekehrt, war Basic 
eigentlich ein Fortran für die kleinen Heimcomputerfreunde.
Wenn dann in den Schulen Basic präsent war, dann war der Umstieg, 
zumindest in der Matheabteilung nicht so weit, außerdem hat Fortran ein 
paar Goodies für die Mathe-Programmierung, die es in anderen 
Programmiersprachen nicht gab.
Zu allem Überfluss kann man Julia mit Fortran möglicherweise super 
kombinieren, falls man mal einen (sequentiellen) Turbo braucht ;)

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Rbx schrieb:
> Jörg W. schrieb:
>> FORTRAN war anders seltsam :-)

> Fortran war der große Bruder von Basic. Oder umgekehrt, war Basic
> eigentlich ein Fortran für die kleinen Heimcomputerfreunde.
> Wenn dann in den Schulen Basic präsent war, dann war der Umstieg,
> zumindest in der Matheabteilung nicht so weit, außerdem hat Fortran ein
> paar Goodies für die Mathe-Programmierung, die es in anderen
> Programmiersprachen nicht gab.

"computed GOTO" und "arithmetic IF" zum Beispiel. :-)

SCNR …

von Rbx (rcx)


Lesenswert?

Jörg W. schrieb:
> computed GOTO" und "arithmetic IF" zum Beispiel. :-)

Immerhin kann man sich recht gut die Übersetzung nach Assembler 
vorstellen.
Das geht bei verschachtelten Schleifen nicht mehr so gut und noch 
schwieriger bei schlimmeren Abstraktionen wie OOP z.B. Aber OOP..(wird 
das dann nicht auch leichter verständlich?) ..
Jedenfalls kann man bei neueren Fortran-Ausgaben auch OOP nutzen, und 
schaut man sich Diskussionen an, kann man doch Lust bekommen, sich seine 
eigenen Dokus zu OOP nochmal anzusehen.
Oder man denkt sich so: fehlen vielleicht noch ein paar richtig gute 
Java-Programmierer im Team?

https://www.researchgate.net/publication/2644517_Performance_Benchmarking_of_Object_Oriented_MPI_OOMPI_Version_102g

https://fortran-lang.discourse.group/t/a-cautionary-tale-on-object-oriented-programming/5674

: Bearbeitet durch User
von Sheeva P. (sheevaplug)


Lesenswert?

Hans W. schrieb:
> Aber um das geht es mir aber nicht!
> Mir gefällt die Sprache nicht. Punkt!

Die Vielzahl Deiner Ausrufezeichen und Dein "Punkt!" scheinen mir 
Indizien dafür zu sein, wie emotional Du an die Sache herangehst.

> Und warum wirfst du mir dann vor, dass ich Python mir einfach nicht gut
> genug angesehen habe?

Ich kann nicht für den anderen Herrn sprechen, bemerke jedoch dass Du 
auf kein einziges seiner Sachargumente eingehst. Zum Beispiel hattest Du 
behauptet dass Python sich nicht in verteilten Clustern benutzen ließe. 
"Ein Typ" hat mehrere Ansätze aufgezeigt mit denen genau das 
funktioniert. Aber obwohl Du sehr viele Worte schreibst gehst du mit 
keinem einzigen darauf ein.

Des Weiteren ist es ja so dass Du Dinge behauptest die einfach falsch 
sind, wie zum Beispiel das mit dem Clustering. Da gibt es nur zwei 
Möglichkeiten: entweder Du weißt es nicht besser, hast Dir Python also 
"einfach nicht gut genug angesehen", oder Du lügst bewusst.

> Ich weiß nicht, warum die Python Community mit solchen Nachdruck zu
> missionieren  versucht.

Ich hatte nicht den Eindruck dass "Ein Typ" missioniert hätte. Er hat 
nur Deine Falschaussagen (siehe oben) richtig gestellt.

Mir dagegen fallen die Emotionalität und die Intensität auf, mit der 
manche Menschen gegen Python missionieren. Emotionen scheinen dabei oft 
eine viel größere Rolle zu spielen als eine professionell sachliche 
Betrachtung.

von Sheeva P. (sheevaplug)


Lesenswert?

Rbx schrieb:
> Das Python Problem ist halt: du kannst nicht mal eben den Compiler bzw
> Interpreter umschreiben und "Maschinen-Tunings" gehen halt auch nicht,
> sondern man kann meist nur das nehmen, was schon da ist.

In C, C++ oder Haskell schreibt man seinen Compiler oder Interpreter um? 
Und was hindert einen Python-Entwickler daran, andere Bibliotheken zu 
nutzen?

> Was am Ende
> dazu führt, dass etliche Python Programmierer verzweifelt fragen, wie
> kann ich mein Programm schneller rechnen lassen.
>
> https://www.netlib.org/lapack/lug/node140.html
> 
https://stackoverflow.com/questions/68234466/scipy-blas-lapack-force-use-of-avx-instruction-set
> https://discourse.julialang.org/t/about-julias-inline-assembly-usage/30352

Lustig dass kein einziger Deiner Links auch nur entfernt etwas mit 
Python zu tun hat. Hast Du Deine eigenen Links nicht gelesen?

von Rbx (rcx)


Lesenswert?

Sheeva P. schrieb:
> Lustig dass kein einziger Deiner Links auch nur entfernt etwas mit
> Python zu tun hat.

Lustig, dass es in diesem Thread überhaupt nicht um vorrangig Python 
geht.

von Giovanni (sqrt_minus_eins)


Lesenswert?

als Beitrag zur Diskussion über verschiedene Programmiersprachen.

https://jcarroll.com.au/2024/10/26/polyglot-maxxie-and-minnie/

APL kannte ich bisher nicht. Finde die Syntax aber cool.

von Sheeva P. (sheevaplug)


Lesenswert?

Rbx schrieb:
> Sheeva P. schrieb:
>> Lustig dass kein einziger Deiner Links auch nur entfernt etwas mit
>> Python zu tun hat.
>
> Lustig, dass es in diesem Thread überhaupt nicht um vorrangig Python
> geht.

Warum kommt das Wort Python dann neun Mal in Deinem Beitrag vor?

Beitrag "Re: Welche Programmiersprache für numerische Rechnungen"

von Klaus (feelfree)



Lesenswert?

Giovanni schrieb:
> APL kannte ich bisher nicht. Finde die Syntax aber cool.

Cool im Sinne von Cool oder im Sinne von WTF???

Für mich ist das, was im Screenshot zu sehen ist, seehr nahe an 
Brainfuck.
Für gelernte Mathematiker mag das anders sein.

von Sheeva P. (sheevaplug)


Lesenswert?

Rbx schrieb:
> Was will man Leuten erzählen, die meinen, man kann mit Python alles
> machen, schließlich ist Python auch bewährte effektive
> Hackerprogrammiersprache?

Nebenbei stellt sich mir gerade die Frage warum Du glaubst dass man 
Python-Entwicklern unbedingt etwas erzählen müsse?

> Wobei bei Haskell vor allem die Doubles (und nicht die Floats)
> eingesetzt werden sollten, wegen einer besseren Performance.
> Die Probleme mit Fließkommazahlen werden dann allerdings nicht behoben.
> Fließkommafehler bei Haskell?
> http://wiki.haskell.org/Performance/Floating_point
> scheinbar nicht bekannt. Ganz anders Python:
> https://docs.python.org/3/library/decimal.html

Hast Du Deine Links nicht gelesen oder nicht verstanden? In Deinem Link 
steht nicht dass Double eine bessere Performance hätte als Float. Da 
steht dass die Verwendung von Double "rarely a speed disadvantage" hätte 
also: "selten einen Geschwindigkeitsnachteil". Von einem 
Geschwindigkeitsvorteil wie Du ihn hier behauptest steht dort nichts.

Dazu steht in der Dokumentation zum Glasgow Haskell Compiler (GHC) auch 
noch diese Aussage [1] zum Datentyp Double: "It is desirable that this 
type be at least equal in range and precision to the IEEE 
double-precision type". Haskell orientiert sich also an haargenau 
demselben Standard (IEEE-754) wie Python.

[1] 
https://hackage.haskell.org/package/base-4.20.0.1/docs/GHC-Float.html#g:8

von Sheeva P. (sheevaplug)


Lesenswert?

Klaus schrieb:
> Für gelernte Mathematiker mag das anders sein.

Ich glaub für die ist das auch gemacht... :)

von Rbx (rcx)


Lesenswert?

Sheeva P. schrieb:
> Warum kommt das Wort Python dann neun Mal in Deinem Beitrag vor?

Sheeva P. schrieb:
> Warum kommt das Wort Python dann neun Mal in Deinem Beitrag vor?
>
> Beitrag "Re: Welche Programmiersprache für numerische Rechnungen"

Das ergibt sich aus dem Zusammenhang. Tut mir ja leid, dass du den 
Zusammenhang mit der Ausgangsfrage nicht verstehst, und deswegen einen 
auf Graf Zahl machen musst. Man könnte ja auch ein MinMax-Prinzip 
vermuten, sich selber gar nicht anstrengen, wenn es um tieferes 
Verständnis geht - und wenn schwierige Fragen auftauchen, einfach vom 
Thema weg antworten, Mutter beleidigen, publikumswirksame 
Wertverletzungen unterstellen usw.
Oder einfach kurz: suchst du Streit, oder was?

Versuche lieber mal ein paar Mitlesern zu erklären, wie du deine 
Pythonprogramme beschleunigst, wenn es um Wetterberechnung, Bitcoin oder 
einfach Wirtschafts-Hpc geht.

von Vanye R. (vanye_rijan)


Lesenswert?

> "computed GOTO" und "arithmetic IF" zum Beispiel. :-)

Nee, COMPLEX!

Ich hab nen Schein in Fortran gemacht, ich weiss das. :-D

Vanye

von Sheeva P. (sheevaplug)


Lesenswert?

Rbx schrieb:
> Sheeva P. schrieb:
>> Warum kommt das Wort Python dann neun Mal in Deinem Beitrag vor?
>>
>> Beitrag "Re: Welche Programmiersprache für numerische Rechnungen"
>
> Das ergibt sich aus dem Zusammenhang.

Welcher Zusammenhang? Du schreibst einen Beitrag in dem neun (9) Mal das 
Wort Python vorkommt und in dem Du behauptest, das "Python Problem" sei 
dass man "nicht mal eben den Compiler oder Interpreter umschreiben" 
könne. Auf meine verwunderte Gegenfrage ob man das denn in C, C++ oder 
Haskell tun würde, hast Du bisher leider keine Antwort gefunden.

Direkt danach behauptest Du, dass "etliche Python Programmierer 
verzweifelt fragen, wie kann ich mein Programm schneller rechnen 
lassen", und postest dann direkt drei Links. Naiv wie ich bin war ich 
jetzt davon ausgegangen dass Deine Links Deine Behauptung mit den 
"etlichen" belegen würden. In Wirklichkeit geht es in Deinem Links aber 
um LAPACK, um die Nutzung von Intels AVX- und AVX2-Instruktionssätze und 
im dritten um die Sprache Julia.

Meine Gegenfrage was Deine Links mit Python zu tun haben, über das Du 
vorher und nachher redest, belehrst Du mich dass es in diesem Thread 
nicht vorrangig um Python gehe. Und meinen Hinweis, dass Du zuvor 
Deinerseits sehr ausführlich über Python geredet hast, konterst Du mit:

> Oder einfach kurz: suchst du Streit, oder was?

Nö, dazu sehe ich bisher noch keine Veranlassung. Allerdings befürchte 
ich, dass es zum Streit kommen kann, wenn Du weiterhin zusammenhanglosen 
Bullshit über Python erzählst und den mit wirren Links auf vollkommen 
andere Themen zu "belegen" versuchst. Wenn Du Deinerseits keinen Streit 
suchst könntest Du es einfach unterlassen solchen Unfug zu schreiben und 
alles wäre fein.

Denn ich habe wirklich überhaupt kein Problem damit wenn Du und Hans 
Python nicht mögt. Niemand muss irgend etwas mögen. Nicht einmal Python. 
Aber wenn Ihr Bullshit darüber sabbelt, stelle ich das richtig. 
Zweifellos lesen hier nämlich Leute mit die sich nicht so gut auskennen 
und halten Euren Bullshit dann womöglich noch für zutreffend. Wir wollen 
doch nicht irreführen, oder?

> Versuche lieber mal ein paar Mitlesern zu erklären, wie du deine
> Pythonprogramme beschleunigst, wenn es um Wetterberechnung, Bitcoin oder
> einfach Wirtschafts-Hpc geht.

Für Interessierte gibt es da ein wundervolles Buch namens "High 
Performance Python" [1], das verschiedene performancekritische Aspekte 
der Sprache wie Speicherverwaltung, Parallelisierung, Profiling, die 
Kompilation von Python- in Maschinencode, die Nutzung von Clustern und 
weitere Themen anspricht. Für Anfänger ist dieses Buch nicht die erste 
Wahl.

Ich selbst verwende je nach Aufgabe Frameworks wie numpy, Numexpr, 
scipy, Tensorflow/Keras, PyTorch, Caffe2, spaCy, Theano, Pyro, PyBrain, 
Cuda und natürlich Pandas, pandarallel und neuerdings auch Vulkan. Wenn 
die alle nicht bieten was ich brauche schreibe ich mir eigene 
Erweiterungen in C oder Cpp, letztere meistens mit Boost.Python. Häufig 
birgt auch der optimierte Pypy-Interpreter mit seinem 
Just-in-Time-Compiler grosse Performancegewinne. Die Compiler nuitka und 
numba wurden in diesem Thread IIRC schon genannt?

[1] 
https://www.amazon.com/High-Performance-Python-Performant-Programming/dp/1492055026

von Sheeva P. (sheevaplug)


Lesenswert?

Giovanni schrieb:
> Julia setzt auf multiple dispatching - satt object oriented programming.
> Das ist schon mal ganz anders, eröffnet aber viele Möglichkeiten.
> Was mich aber beeindruckt hat, ist MetaProgramming. Also Programmteile
> erst zur Laufzeit zu erstellen. Interessant in der Simulationen & ML, wo
> Gleichungen symbolisch differenziert werden müssen.
> siehe : https://github.com/sciml

Lieben Dank für die Erklärungen und den Hinweis. Was ich bisher gesehen 
habe gefällt mir ausgesprochen gut.

Ich habe gerade die Library Redis.jl [1] angeschaut, die benutzt einfach 
die Funktionen set() und get() mit einer Instanz von RedisConnection() 
als erstem Argument. Verstehe ich das mit dem multiple dispatching 
richtig, dass mehrere Pakete Funktionen get() und set() definieren und 
Julia an den Argumenttypen erkennt, welche Methode aus welchem Paket 
aufgerufen wird? Das würde ja dem Überladen von Methoden aus C++ ähneln, 
oder bin ich auf dem Holzweg?

[1] https://github.com/JuliaDatabases/Redis.jl

von Re D. (re_d228)


Lesenswert?

Ich denke Leute Rbx kommen nicht damit klar, dass heute "jeder Depp" mit 
Python Probleme besser lösen kann, als er, wo er vor 40 Jahren viel 
Schweiß und Blut investieren musste. Das führt dann zu solch emotionalen 
Reaktionen. Es ist doch so, das wir in einer arbeitsteiligen 
gesellschaft leben. Es gibt Leute die können super effiziente Programme 
für das lösen numerischer Gleichungen schreiben, es reicht aber wenn das 
ein paar in der Sprache ihrer Wahl tun. Andere haben Probleme, die sie 
numerisch lösen wollen, die befassen sich mit dem Problem, nicht mit 
bare metal Programmierung. Der Zeitaufwand dich da in alle Details 
einzuarbeiten ist viel zu groß und 99,9999% werden nix besseres 
abliefern, als es schon gibt. Rbx gehört sicher zu den 0,0001%. Dafür 
hat er halt Probleme vernünftige rote Linien in seine Argumentation zu 
bringen.

von Giovanni (sqrt_minus_eins)


Lesenswert?

Sheeva P. schrieb:
> Das würde ja dem Überladen von Methoden aus C++ ähneln,
> oder bin ich auf dem Holzweg?

Sehe ich auch so.
ein sehr einfaches Beispiel:
1
show wird immer aufgerufen wenn ich "MeineDaten" anzeigen will
2
struct MeineDaten
3
  a::String
4
end
5
6
function Base.show(io::IO, info::MeineDaten)
7
  printstyled("$(info.a)", color=:red)
8
  ...
9
end

https://github.com/bkamins  für Einsteiger DataFrames

https://www.juliabloggers.com/  immer mit interessanten Beiträgen.

https://github.com/CedarEDA/CedarSim.jl   soll ein Spice Simulator 
werden. Hier geht man aber schon in den Compiler rein um die Performance 
zu verbessern (nichts für mich).

Generelle Frage: Programmiersprachen sind ja nicht statisch, sondern 
werden immer wieder erweitert.

* Wer verwendet den vollen Sprachumfang von Python 3.12?? Ehrlich. Ich 
komme mit dem Umfang Python2.7 aus.

* Wer verwendet OOP in Fortran?

* Wer verwendet OOP in MATLAB?

Mein Eindruck: Die Sprachen werden sich immer ähnlicher. Ob OOP in 
FORTRAN Sinn macht, ist mir nicht klar.

: Bearbeitet durch User
von Vanye R. (vanye_rijan)


Lesenswert?

> Ich denke Leute Rbx kommen nicht damit klar, dass heute "jeder Depp" mit
> Python Probleme besser lösen kann, als er, wo er vor 40 Jahren viel
> Schweiß und Blut investieren musste.

Ich stimme dir zu wenn es sich um gute abgeschlossene Libraries handelt 
und eine Mathelibrarie die viele Menschen auf der Welt nutzen gehoert 
sicher dazu. Ja, dann ist das ein Vorteil. Aber Problem ist leider das 
viele es auf Faulheit nutzen um doof bleiben zu wollen und selbst banale 
Sachen nicht mehr verstehen wollen und dann wiederum wackelige 
Murkssoftware produzieren.

Hat also alles so seine Vor und Nachteile. .-)

Allerdings bin ich manchmal noch Bonusgenervt wenn Library XY die 
Compilerwersen XZ braucht, und man bei aenderungen dann zehn alte 
Projekte nachziehen muss weil die leider nur mit Comilerversion AB gut 
liefen.

Vanye

von Jan K. (jan_k776)


Lesenswert?

Giovanni schrieb:
> Wer verwendet den vollen Sprachumfang von Python 3.12?? Ehrlich. Ich
> komme mit dem Umfang Python2.7 aus.
>

Ich nutze modernes Python.

> Wer verwendet OOP in Fortran?
>
Kp

> Wer verwendet OOP in MATLAB?

Ich. Massiv. Fast alle Neuentwicklungen in MATLAB bei uns sind 
klassenbasiert. Die Sprache hat sich extrem weiterentwickelt.

Wenn man Apps/GUIs entwickelt kommt man daran auch gar nicht mehr dran 
vorbei (glücklicherweise)

von Rbx (rcx)


Lesenswert?

Giovanni schrieb:
> Mein Eindruck: Die Sprachen werden sich immer ähnlicher. Ob OOP in
> FORTRAN Sinn macht, ist mir nicht klar.

Oft sind wichtige Bibs auch noch in Fortran 77 geschrieben.

Dein Link oben 
(https://jcarroll.com.au/2024/10/26/polyglot-maxxie-and-minnie/) hatte 
mich ein wenig angefixt, weil ich so dachte: hey, wie könnte man sowas 
in Assembler schreiben. Ist aber auf den ersten Blick nicht so einfach, 
weswegen ich mich dann etwas umgesehen hatte:

- https://rosettacode.org/wiki/Sorting_algorithms/Permutation_sort
- https://www.nature.com/articles/s41586-023-06004-9#code-availability
- https://rosettacode.org/wiki/Sorting_algorithms/Insertion_sort
- https://ceur-ws.org/Vol-2568/paper4.pdf
(- https://github.com/ostafen/Fast-Insertion-Sort)
usw..
Beim Durchlesen beim rosettacode dachte ich auch gleich, man könnte auch 
wieder was mit D machen. Ist zwar nicht unbedingt für MCs, aber 
performant ist D schon, nur leider etwas verwaist.

Re D. schrieb:
> Ich denke Leute Rbx kommen nicht damit klar, dass heute "jeder Depp" mit
> Python Probleme besser lösen kann, als er, wo er vor 40 Jahren viel
> Schweiß und Blut investieren musste.

Ich habe nichts gegen Python, im Gegenteil, nur eben mit dem Auftreten 
von Sheeva und Ein T 
(https://de.wikipedia.org/wiki/Der_seltsame_Fall_des_Dr._Jekyll_und_Mr._Hyde)
Es ist immer die selbe Nummer: Versuchen, eine lange Diskussion 
anzustoßen, dann auch zwischendurch persönlich werden, oder sich 
persönlich angegriffen fühlen, oder umgekehrt den Leuten immer wieder 
schön auf die Füsse treten usw.
-> kein bisschen hilfreich, kein bisschen konstruktiv, einfach nur 
Flame-Wars (o.ä.) anzetteln - dabei hatte ich Sheeva früher schon als 
hilfreich empfunden.

von Rainer W. (rawi)


Lesenswert?

Hannes J. schrieb:
> Bist du dir sicher, dass deine "aufwendigen Rechnungen" heute noch als
> aufwendig gelten?

Bei Wettermodellen kannst du jeden beliebigen Rechenaufwand erzeugen, 
indem du an den Gittergrößen drehst. Da ist es egal, ob der Algorithmus 
von 1990 oder von 2024 stammt. Bei Spielen kannst du statt dessen 
Frameraten und Auflösung hochschrauben. Oder frag mal irgendwelche 
Großteleskope mit adaptiver Optik mit ihren Aktuatorzahlen und 
Aktualisierungsrate.
Da kann man auch heutige Rechner gut beschäftigen und über Scripting die 
Zeit tot zu schlagen.

: Bearbeitet durch User
von Re D. (re_d228)


Lesenswert?

Rainer W. schrieb:
> Bei Wettermodellen kannst du jeden beliebigen Rechenaufwand erzeugen,
> indem du an den Gittergrößen drehst.

Es gibt aber Grenzwerte, ab denen die Verkleinerung des Netzes keinen 
Mehrwert an Information liefert.

Rbx schrieb:
> Ich habe nichts gegen Python, im Gegenteil, nur eben mit dem Auftreten
> von Sheeva und Ein T

Doch du hast ein Problem. Deine Äußerungen sind weder objektiv noch 
konstruktiv.

von Rbx (rcx)


Lesenswert?

.Re D. schrieb:
> Doch du hast ein Problem. Deine Äußerungen sind weder objektiv noch
> konstruktiv.
Fass dich an die eigene Nase, und höre auf Threadantworten zu 
verwechseln, zu vermischen oder zu vertauschen.

von Franko S. (frank_s866)


Lesenswert?

Python verwendet man nur wegen der vielen angeflanschten Bibliotheken, 
nicht wegen der "Schönheit" der Sprache oder Platform, da ist das grösse 
Müll und bietet absolut nix neues und kann nix richtig gut. Threads sind 
kaputt, die generelle Interprester-Performance ist unterirdisch im 
vergleich zu Java geradezu vorsinflutlich, die Versuche das alles zu 
verbessern sind mangelhaft und nicht offiziell (Jython, Cython, 
Schlagmichtot-thon).
Das Objektsystem ist auch mangelhaft, funktionale Unterstützung wurde 
wieder rausgekickt, den Hirnfurzn dass Whitespace Syntaxelement ist muss 
man da gar nicht mehr erwähnen nach den ganzen viel grösseren Mängeln.
Ich frage mich warum man diesen Mist explizit einsetzen will, aussern 
den Sahnebibliotheken aus dem KI-Bereich, OpenCV,... und bischen 
numerischer Rechnungen.
Die Sprache finden nur Kinder und Idioten toll die noch nie was anderes 
gesehen haben wie früher die BASIC-Fans, so fühlt sich dieser 
Kindersprache auch an. Man muss nur mal schauen wie der Buchmarkt für 
Pyhton aussieht: 99% Anfängerbücher auf allerunterstem Level, oft so 
Namen wie "Pyhton für Kinds" und ähnlicher banaler Schrott, der Rest ist 
Python nur Beiwerk weil es um die entspr. libs wie Tensorflow, 
PySpark,... geht und nicht die Deppensprache.

Python braucht kein Mensch, das wurde nur populär durch die Entscheidung 
der big player ihre Edellibs im oben genannten Bereich dort ranzupappen, 
was wohl auch damit zu tun hat dass US-Hochschulen sich verstärkt auf 
Python als Deppenlehrsprache eingeschossen haben, die Kinder sind ja 
heute generell zu doof für alles, das muss alles kindgerecht sein.

: Bearbeitet durch User
von Oliver S. (oliverso)


Lesenswert?

Franko S. schrieb:
> Ich frage mich warum man diesen Mist explizit einsetzen will,

Ganz einfach. Nachdem alle anderen Programmiersprachen über die Zeit aus 
guten Gründen über Typsicherheit und ähnliches den "programmatischen 
Freiraum" des Programmierers sichtlich eingeschränkt haben, musste halt 
wieder was her, in dem sich völlig befreit von solchen Zwängen fröhlich 
drauflosgehackt werden konnte. Quick and dirty als Konzept.

Oliver

von Re D. (re_d228)


Lesenswert?

Franko S. schrieb:
> Python braucht kein Mensch, das wurde nur populär durch die Entscheidung
> der big player ihre Edellibs im oben genannten Bereich dort ranzupappen,
> was wohl auch damit zu tun hat dass US-Hochschulen sich verstärkt auf
> Python als Deppenlehrsprache eingeschossen haben, die Kinder sind ja
> heute generell zu doof für alles, das muss alles kindgerecht sein.

Oliver S. schrieb:
> Ganz einfach. Nachdem alle anderen Programmiersprachen über die Zeit aus
> guten Gründen über Typsicherheit und ähnliches den "programmatischen
> Freiraum" des Programmierers sichtlich eingeschränkt haben, musste halt
> wieder was her, in dem sich völlig befreit von solchen Zwängen fröhlich
> drauflosgehackt werden konnte. Quick and dirty als Konzept.


Ersetzen wir Rbx durch Rbx, Franko S. und Oliver S.:

Re D. schrieb:
> Ich denke Leute Rbx kommen nicht damit klar, dass heute "jeder Depp" mit
> Python Probleme besser lösen kann, als er, wo er vor 40 Jahren viel
> Schweiß und Blut investieren musste.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Franko S. schrieb:
> Die Sprache finden nur Kinder und Idioten toll

Da ich vermutlich nicht mehr als Kind durchgehe, bin ich wohl ein Idiot.
Na ja, schlimmer fände ich es, wenn mich jemand als Scheuklappenträger
bezeichnen würde ;-)

von Norbert (der_norbert)


Lesenswert?

Franko S. schrieb:
> …

Enorme Mengen dummes Zeug. Welches schon beim Lesen so dermaßen wehtut, 
dass man vermuten muss da wird jemand kontinuierlich vom Schwein 
gebissen um so etwas abzusondern.

Erstaunlich mit welchen Individuen man sich diesen Planeten teilen muss.

: Bearbeitet durch User
von Rbx (rcx)


Lesenswert?

Re D. schrieb:
> Ersetzen wir Rbx durch Rbx, Franko S. und Oliver S.:
>
> Re D. schrieb:
>> Ich denke Leute Rbx kommen nicht damit klar, dass heute "jeder Depp" mit
>> Python Probleme besser lösen kann, als er, wo er vor 40 Jahren viel
>> Schweiß und Blut investieren musste.

Ja Pippi.

von Re D. (re_d228)


Lesenswert?

Rbx schrieb:
> Ja Pippi.

Ich bin hier nicht der, der behauptet mal eben schnell den Compiler 
umzuschreiben. Komm zu Thema zurück oder lass es.

von Ein T. (ein_typ)


Lesenswert?

Oliver S. schrieb:
> Nachdem alle anderen Programmiersprachen über die Zeit aus
> guten Gründen über Typsicherheit und ähnliches den "programmatischen
> Freiraum" des Programmierers sichtlich eingeschränkt haben, musste halt
> wieder was her, in dem sich völlig befreit von solchen Zwängen fröhlich
> drauflosgehackt werden konnte. Quick and dirty als Konzept.

Ja, äh... falsch. "Quick and dirty" machen Perl, PHP und Lua, und die 
sind nicht typsicher. Python (und nebenbei auch Ruby) sind hingegen 
typsicher, deswegen führt die Addition einer Ganzzahl und eines Zeichens 
("1 + '1'") unter Python auch zu dem Fehler
1
Traceback (most recent call last):
2
  File "<stdin>", line 1, in <module>
3
TypeError: unsupported operand type(s) for +: 'int' and 'str'

und unter Ruby zu dem Fehler
1
-:1:in `+': String can't be coerced into Integer (TypeError)
2
        from -:1:in `<main>'

Du siehst: Python und Ruby sind durchaus typsicher, sie händeln das nur 
ein bisschen anders als die klassischen statisch typisierten Sprachen. 
Python und Ruby binden den Datentyp nämlich nicht an den Namen einer 
Variablen, sondern an ihren Wert.

Deswegen gibt es für Python auch die Type Hints sowie mypy [1] und für 
Ruby gibt es Sorbet [2]. Damit werden genau dieselben Typprüfungen 
durchgeführt, wie das in statischen kompilierten Sprachen vom Compiler 
gemacht wird. So erhalten die Entwickler die Vorzüge aus beiden Welten: 
einerseits die sehr schnelle und einfache Entwicklung, andererseits 
werden die Typen vor einem Release noch einmal geprüft und mögliche 
Fehler erkannt. Außerdem ist es natürlich fein, daß die Datentypen 
bereits im Code stehen und darum nicht separat dokumentiert werden 
müssen.

[1] https://mypy-lang.org/
[2] https://sorbet.org/

von Re D. (re_d228)


Lesenswert?

Franko S. schrieb:
> Python verwendet man nur wegen der vielen angeflanschten Bibliotheken,
> nicht wegen der "Schönheit" der Sprache

Hat du da einen Beleg? Ich finde Python sehr schön und gut leserlich. 
Aber klar man kann in jeder Syntax hässliches Zeug machen. Es gibt Leute 
die mögen Schachtelsätze weil sie damit intelligent wirken, es gibt 
Leute die können auch komplizierte Zusammenhänge einfach ausdrücken. 
Aber was schön ist, ist völlig subjektiv.

Franko S. schrieb:
> da ist das grösse Müll und bietet absolut nix neues und kann nix richtig
> gut.

Okay, welche Alternative zu mathplotlib empfiehlst du? Die Sprache soll 
bitte auch etwas äquivalentes zu f-Strings bieten.

Franko S. schrieb:
> Threads sind kaputt, die generelle Interprester-Performance ist
> unterirdisch im vergleich zu Java geradezu vorsinflutlich,

Was heißt Threads sind kaputt? Und die Performance ist trotzdem für 
vieles ausreichend. Ansonsten wurde genug genannt zur Beschleunigung.

Franko S. schrieb:
> Das Objektsystem ist auch mangelhaft, funktionale Unterstützung wurde
> wieder rausgekickt,

Was bitte ist zu bemängeln? Da bin ich neugierig.

Franko S. schrieb:
> den Hirnfurzn dass Whitespace Syntaxelement ist muss man da gar nicht
> mehr erwähnen

Vielleicht fehlt dir das Hirn das Konzept zu verstehen? Sagst du bei 
Fortran 77 da gleiche?

Franko S. schrieb:
> Ich frage mich warum man diesen Mist explizit einsetzen will, aussern
> den Sahnebibliotheken aus dem KI-Bereich, OpenCV,...

Weil es eine schöne und offene Sprache ist mit großer Community ❤️?

Franko S. schrieb:
> und bischen numerischer Rechnungen.

Als ist Python gut für Numerik? Da sind wir ja beim Thema.

Franko S. schrieb:
> Die Sprache finden nur Kinder und Idioten toll die noch nie was anderes
> gesehen haben

So so, woran machst du das fest? Und hast du was gegen Kinder? Die sind 
nicht so engstirnig wie du?

Franko S. schrieb:
> Man muss nur mal schauen wie der Buchmarkt für Pyhton aussieht: 99%
> Anfängerbücher auf allerunterstem Level, oft so Namen wie "Pyhton für
> Kinds" und ähnlicher banaler Schrott,

Ach und wie ist das bei anderen Sprachen? Wenn man sich eingearbeitet 
hat, braucht man in Python kein Buch, es gibt die Doku frei im Interner: 
python.org ist dein Freund. Aber für dich scheint das Neuland zu sein. 
Nenn doch mal eine Sprache, die was vergleichbares bietet.

Franko S. schrieb:
> der Rest ist Python nur Beiwerk weil es um die entspr. libs wie
> Tensorflow, PySpark,... geht und nicht die Deppensprache.

Was denkst du, warum die Entwickler die Deppensprache (Nur Deppen 
benutzen so ein Wort) supporten. Weil sie dumm und du schlau bist? Da 
musst du ja noch viel besseres Zeug auf Lager haben. Zeug mal!

Franko S. schrieb:
> Python braucht kein Mensch,

Gott sei Dank, hat du nicht zu entscheiden, wer was braucht und wer 
Mensch ist.

Franko S. schrieb:
> das wurde nur populär durch die Entscheidung der big player ihre
> Edellibs im oben genannten Bereich dort ranzupappen, was wohl auch damit
> zu tun hat dass US-Hochschulen sich verstärkt auf Python als
> Deppenlehrsprache eingeschossen haben, die Kinder sind ja heute generell
> zu doof für alles, das muss alles kindgerecht sein.

Ja, die trinken Kinderblut und werden von Reptiloiden regiert.

von Ein T. (ein_typ)


Lesenswert?

Re D. schrieb:
> Ersetzen wir Rbx durch Rbx, Franko S. und Oliver S.:

Es fällt RBX zwar manchmal schwer, seine Aussagen in einen stimmigen 
Kontext mit einer nachvollziehbaren Reihenfolge zu bringen, und 
Rückfragen zu seinen Äußerungen zu beantworten. Aber im Gegensatz zu 
Franko S und Oliver S ist er ganz sicher kein Troll.

von Ein T. (ein_typ)


Lesenswert?

Re D. schrieb:
> Ich finde Python sehr schön und gut leserlich.
> Aber klar man kann in jeder Syntax hässliches Zeug machen.

Na, ich persönlich sehe in Python einige Unterschiede zu anderen 
Sprachen. Der erste ist, daß ich in Perl sehr diszipliniert sein und mir 
Mühe geben muß, um les- und wartbaren Code zu schreiben. In Python muß 
ich diszipliniert sein und mir Mühe geben, um unles- und unwartbaren 
Code zu schreiben.

Nicht umsonst wird Python oft als "ausführbarer Pseudocode" bezeichnet. 
Zum Einen benutze ich Python-Syntax häufig beim Kommentieren von Code in 
anderen Sprachen, um bestimmte Abläufe und Algorithmen zu erläutern. Zum 
anderen hat Python für mich den Vorteil, daß ich meine Gedanken direkt 
aus dem Gehirn in meinen Editor tippen kann, ohne darüber nachdenken zu 
müssen, wie ich meinen Gedanken jetzt genau in meiner Zielsprache 
formulieren muß.

Um der Vermutung vorzubeugen, daß das daran läge, daß ich Python nun 
schon so lange mache und deswegen daran gewöhnt bin: nein, in meinem 
Fall ist das ganz sicher nicht der Fall. Ich bin von C, C++ und Perl zu 
Python gekommen, war am Anfang auch -- nicht nur wegen der Sache mit dem 
Whitespace -- skeptisch, und diese einfache Gehirn2Editor-Eigenschaft 
war das allererste, was mir schon am ersten Tag mit Python sehr positiv 
aufgefallen ist.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Ein T. schrieb:
> Na, ich persönlich sehe in Python einige Unterschiede zu anderen
> Sprachen. Der erste ist, daß ich in Perl sehr diszipliniert sein und mir
> Mühe geben muß, um les- und wartbaren Code zu schreiben. In Python muß
> ich diszipliniert sein und mir Mühe geben, um unles- und unwartbaren
> Code zu schreiben.

Das sehe ich allerdings nicht so. Selbstverständlich hat jeder 
vernünftige Programmierer irgendeinen Programmierstil, der auch 
Einrückungen einschließt – egal in welcher Sprache, also auch in Perl. 
Nur, weil sie nicht syntaktisch relevant sind, heißt das ja nicht, dass 
sie in der Regel weggelassen würden.

Außerdem habe ich auch schon genügend Python-Programme gesehen, die 
unleserlich genug sind, als dass man letztere Aussage so nicht stehen 
lassen kann.

Es steht und fällt immer mit dem Programmierer selbst, wie das Ergebnis 
aussieht.

(Objektsystem)

Re D. schrieb:
> Was bitte ist zu bemängeln?

Es gibt da hin und wieder Inkonsequenzen, fällt einem meistens erst auf, 
wenn man drüber stolpert. Meine Lieblings-Inkonsistenz wäre, dass len 
ein Operator statt eine Methode eines Objekts ist.

: Bearbeitet durch Moderator
von Re D. (re_d228)


Lesenswert?

Jörg W. schrieb:
> Meine Lieblings-Inkonsistenz wäre, dass len
> ein Operator statt eine Methode eines Objekts ist.

len() ist eine Funktion, genauso wie range(). Die Funktion ruft die 
Methode __len__() eines Objekts auf. Was soll daran inkonsistent sein?

von Re D. (re_d228)


Lesenswert?

Jörg W. schrieb:
> Außerdem habe ich auch schon genügend Python-Programme gesehen, die
> unleserlich genug sind, als dass man letztere Aussage so nicht stehen
> lassen kann.
>
> Es steht und fällt immer mit dem Programmierer selbst, wie das Ergebnis
> aussieht.


Es ist eine Frage der Verteilung.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Re D. schrieb:
> Was soll daran inkonsistent sein?

Dass es keine Methode ist, also nicht objekt.len(), sondern len(objekt).

von Re D. (re_d228)


Lesenswert?

Jörg W. schrieb:
> Re D. schrieb:
>> Was soll daran inkonsistent sein?
>
> Dass es keine Methode ist, also nicht objekt.len(), sondern len(objekt).

Und wo ist da jetzt die Begründung? Wenn du den Sinus von pi haben 
willst, schreibst du doch auch nicht pi.sin() sondern sin(pi). Das ist 
bis jetzt eine Meinung von dir, dass das inkonsistent wäre, aber kein 
Fakt.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Re D. schrieb:
> Wenn du den Sinus von pi haben willst, schreibst du doch auch nicht
> pi.sin() sondern sin(pi).

Nicht alles, was hinkt, ist ein Vergleich.

von Re D. (re_d228)


Lesenswert?

Jörg W. schrieb:
> Re D. schrieb:
>> Wenn du den Sinus von pi haben willst, schreibst du doch auch nicht
>> pi.sin() sondern sin(pi).
>
> Nicht alles, was hinkt, ist ein Vergleich.

Wo bleibt denn jetzt deine Begründung? Und wo hinkt der Vergleich? Da 
hat man dich ertappt, dass du eine Funktion nicht von einen Operator 
unterscheiden kannst und dann kommt nix mehr?

Mir scheint ehr, du hast die Logik und Funktionalität von len() und 
_len_ nicht verstanden.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Re D. schrieb:
> Wo bleibt denn jetzt deine Begründung?

pi ist eine Zahl, kein Objekt.

Aber weder pi noch sin gibt's in Python einfach so.
1
>>> sin(pi)
2
Traceback (most recent call last):
3
  File "<stdin>", line 1, in <module>
4
NameError: name 'sin' is not defined. Did you mean: 'bin'?

Wenn du jetzt anfängst, jede Zahl auch noch als Objekt anzusehen, gut, 
kannst du machen. Dann bräuchtest du halt gar keine Funktionen als 
solche mehr, denn jede Zahl müsste von einer Klasse abgeleitet werden, 
die sowas dann als Methoden mit sich bringt.

Eine Länge wiederum ist etwas, was nur in Verbindung mit manchen 
Objekten überhaupt als Konzept Sinn hat. Das sieht Python übrigens ganz 
genauso:
1
>>> len(3.1415926)
2
Traceback (most recent call last):
3
  File "<stdin>", line 1, in <module>
4
TypeError: object of type 'float' has no len()

Damit ist eigentlich klar, dass die Länge nur als Attribut einiger 
Klassen zweckmäßig ist. Trotzdem wird sie dann aber (entgegen auch der 
Suggestion obiger Fehlermeldung) nicht als Methode gehandhabt, sondern 
als globale Funktion:
1
>>> len(foo)
2
3

funktioniert, also offenbar ist "foo" ein Objekt, für dass die Methode 
einer Länge Sinn hat. Aber es gibt es nicht als Methode:
1
>>> foo.len()
2
Traceback (most recent call last):
3
  File "<stdin>", line 1, in <module>
4
AttributeError: 'list' object has no attribute 'len'

Für dich scheint das völlig logisch zu sein – für mich ist es 
inkonsistent.

Ich kann mit dieser Inkonsistenz leben, aber ich nenne es trotzdem eine 
Inkonsistenz.

von Re D. (re_d228)


Lesenswert?

Jörg W. schrieb:
> pi ist eine Zahl, kein Objekt.

Pi ist ein Objekt vom Typ float.

Jörg W. schrieb:
>>>> sin(pi)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> NameError: name 'sin' is not defined. Did you mean: 'bin'?

Probiere es mit from math import sin, dann bekommst du auch keine 
Fehlermeldung.

Jörg W. schrieb:
> Dann bräuchtest du halt gar keine Funktionen als
> solche mehr, denn jede Zahl müsste von einer Klasse abgeleitet werden,
> die sowas dann als Methoden mit sich bringt.

Ja, macht das der Python-Interpreter.

Jörg W. schrieb:
> Eine Länge wiederum ist etwas, was nur in Verbindung mit manchen
> Objekten überhaupt als Konzept Sinn hat.

Ja, Listen, Tupel, Dictionaries ... alles Objekte. Bei denen macht die 
Funktion sin keinen Sinn, nach deiner Logik müssten also alle Objekte 
vom typ float und int die sin-Funktion haben, denn sonst macht das 
Konzept Sinus doch gar keinen Sinn.

Nein natürlich ist es nicht so! Du verkennst, das Python als 
Multiparadigmen Sprache entworfen ist.

Jörg W. schrieb:
> Damit ist eigentlich klar, dass die Länge nur als Attribut einiger
> Klassen zweckmäßig ist.

Jetzt soll es auch noch ein Attribut sein? Also statt 's'.len() 's'.len? 
Ne, da bin ich nicht bei dir.

Jörg W. schrieb:
>>>> len(foo)
> 3
>
> funktioniert, also offenbar ist "foo" ein Objekt, für dass die Methode
> einer Länge Sinn hat. Aber es gibt es nicht als Methode:
>>>> foo.len()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> AttributeError: 'list' object has no attribute 'len'
>
> Für dich scheint das völlig logisch zu sein – für mich ist es
> inkonsistent.

Ja, weil ich weiß, dass jemand entschieden hat dass len() eine Funktion 
ist die die Länge eines zählbaren Objektes wieder gibt, in dem es die 
Methode __len__() aufruft. "Es wird die Länge gezählt" und das geht mit 
unterschiedlichen Objekttypen. Nur weil du es 20 Jahre anders gemacht 
hast, ist das halt nicht inkonsistent. Es ist einfach anders 
entschieden.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Re D. schrieb:
> Nur weil du es 20 Jahre anders gemacht hast, ist das halt nicht
> inkonsistent. Es ist einfach anders entschieden.

Für dich ist das in Ordnung, weil es jemand so entschieden hat. Für mich 
ist es inkonsistent, weil ich von einem Objekt, welches eine Länge hat, 
eine entsprechende Methode erwarte.

Belassen wir es dabei.

von Re D. (re_d228)


Lesenswert?

Jörg W. schrieb:
> Belassen wir es dabei.

Genau, rein subjektiv und somit kein Beleg, dass die Sprache besonders 
inkonsistent wäre. Sie ist einfach eine Multiparadigmensprache.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Jörg W. schrieb:
> pi ist eine Zahl, kein Objekt.
> ...
> Wenn du jetzt anfängst, jede Zahl auch noch als Objekt anzusehen, gut,
> kannst du machen.

Im Gegensatz zu C++ sind Zahlen in Python tatsächlich Objekte:
1
>>> type(42)
2
<class 'int'>
3
>>> type(3.14)
4
<class 'float'>
5
>>> type(3+4j)
6
<class 'complex'>

Zahlen haben auch Membervariablen und -funktionen:
1
>>> c = 3+4j
2
>>> c.real
3
3.0
4
>>> c.imag
5
4.0
6
>>> c.conjugate()
7
(3-4j)

In Multiparadigmensprachen wie Python, C++ und Java liegt es im Ermessen
des jeweiligen (Bibliotheks- oder Anwendungs-)Entwicklers, welche
Funktionen er als Member- und welche als freie Funktion definiert. Da
Geschmäcker verschieden sind, führt dies immer wieder zu Diskussionen.

In C stellt sich diese Frage nicht: Da sind alle Funktionen frei.

In Smalltalk (reine OO-Sprache) ist die Sache ebenfalls klar: Alle
Funktionen sind Memberfunktionen (also auch abs, sin, cos usw.).

von Ein T. (ein_typ)


Lesenswert?

Jörg W. schrieb:
> Das sehe ich allerdings nicht so. Selbstverständlich hat jeder
> vernünftige Programmierer irgendeinen Programmierstil, der auch
> Einrückungen einschließt – egal in welcher Sprache, also auch in Perl.
> Nur, weil sie nicht syntaktisch relevant sind, heißt das ja nicht, dass
> sie in der Regel weggelassen würden.

Aber wenn wir unseren Code ohnehin korrekt einrücken, sind die {, }, 
begin und end schlicht und ergreifend: redundant, zudem soll die 
Whitespace-Geschichte zu einem besser les- und wartbarem Code führen. 
Das sind die Argumente, die Guido van Rossum für seine 
Designentscheidung vorbringt, und nicht nur, aber auch wegen meiner 
Erfahrungen mit dem Code von anderen Entwickler in anderen Sprachen kann 
ich ihm nur zustimmen. Es ist zweifellos sinnvoll, dafür einen 
ordentlichen Programmiereditor (Emacs, anyone?) zu benutzen, aber das 
ist für Entwickler ja ohnehin sinnvoll und für die meisten wohl auch 
kein Problem.

> Außerdem habe ich auch schon genügend Python-Programme gesehen, die
> unleserlich genug sind, als dass man letztere Aussage so nicht stehen
> lassen kann.

Hättest Du dazu möglicherweise ein, zwei Beispiele für mich? Danke.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Ein T. schrieb:

> Aber wenn wir unseren Code ohnehin korrekt einrücken, sind die {, },
> begin und end schlicht und ergreifend: redundant,

Lahmes Argument, finde ich. Wenn du alles weglassen willst, was 
redundant ist, bleibt nichts menschenlesbares mehr übrig. Auch viele 
Leerzeichen in irgendwelchen Ausdrücken sind redundant, und 
selbstverständlich reichen 6 Zeichen lange Bezeichner komplett aus, um 
genügend Namensraum für alle Programme zu bieten. Hatten wir ja schon 
mit FORTRAN damals. ;-)

> zudem soll die
> Whitespace-Geschichte zu einem besser les- und wartbarem Code führen.

Für mich hat sie sich schon oft als das Gegenteil erwiesen. Die 
Redundanz von {} oder begin … end bringt es nämlich mit sich, dass man 
beispielsweise nach einer größeren copy&paste-Aktion den Code 
automatisch durch eine Maschine neu sortieren lassen kann. Und besser 
lesbar ist Code mit einer gewissen Redundanz ohnehin – siehe Leerzeichen 
innerhalb von Ausdrücken.

>> Außerdem habe ich auch schon genügend Python-Programme gesehen, die
>> unleserlich genug sind, als dass man letztere Aussage so nicht stehen
>> lassen kann.
>
> Hättest Du dazu möglicherweise ein, zwei Beispiele für mich? Danke.

Nein, ich archiviere so einen Kram nicht, wenn ich ihn mal irgendwo 
gesehen habe.

von Norbert (der_norbert)


Lesenswert?

Diese ganze Einrücken-ist-schlecht Diskussion bei Python ist so dermaßen 
überflüssig, dass es der Sau graust!

Als ich vor vielen Jahren damit anfing, hatte ich übrigens die gleichen 
blödsinnigen Vorbehalte. Dann habe ich ein paar Stunden damit gearbeitet 
und nie wieder darüber nachgedacht.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Norbert schrieb:
> Diese ganze Einrücken-ist-schlecht Diskussion bei Python ist so dermaßen
> überflüssig, dass es der Sau graust!

Klar: diese Sprache ändert eh keiner mehr. ;-)

> Als ich vor vielen Jahren damit anfing, hatte ich übrigens die gleichen
> blödsinnigen Vorbehalte.

Bei mir sind es keine Vorbehalte, sondern durchaus die Erfahrungen 
damit. Dabei ist Python wohl die Sprache, in der ich in den letzten 
Jahren (vor allem beruflich) am meisten programmiert habe. Ich weiß also 
durchaus, wovon ich schreibe, und nur weil ich einzelne Aspekte 
kritisiere heißt das nicht, dass ich diese Sprache jetzt insgesamt 
unbenutzbar fände.

von Oliver S. (oliverso)


Lesenswert?

Jörg W. schrieb:
> Wenn du alles weglassen willst, was
> redundant ist, bleibt nichts menschenlesbares mehr übrig.

Was dann zu brainfuck geführt hat, und für die Leerzeichenfetischisten 
zu whitespace.

Oliver

: Bearbeitet durch User
von Ein T. (ein_typ)


Lesenswert?

Jörg W. schrieb:
> Ein T. schrieb:
>> Aber wenn wir unseren Code ohnehin korrekt einrücken, sind die {, },
>> begin und end schlicht und ergreifend: redundant,
>
> Lahmes Argument, finde ich. Wenn du alles weglassen willst, was
> redundant ist,

Das möchte ich ja gar nicht, da bin ich selektiv. :-)

>> zudem soll die
>> Whitespace-Geschichte zu einem besser les- und wartbarem Code führen.
>
> Für mich hat sie sich schon oft als das Gegenteil erwiesen. Die
> Redundanz von {} oder begin … end bringt es nämlich mit sich, dass man
> beispielsweise nach einer größeren copy&paste-Aktion den Code
> automatisch durch eine Maschine neu sortieren lassen kann.

Reden wir gerade von Les- und Wartbarkeit, oder von Kopierbarkeit? Ich 
kenne Deinen Arbeitsalltag und Deine Arbeitsweise natürlich nicht, 
allerdings lese und warte ich Code sehr viel häufiger, als ich welchen 
kopiere. Aber in den seltenen Fällen, in denen ich Code kopiere oder in 
eine andere Datei lege, reichen mir die vielen Indentierungsbefehle (zum 
Beispiel "indent-region-{left,right}-to-tab-stop"), die der Emacs 
mitbringt. IIRC bist Du doch auch ein Emacs-User, oder habe ich das 
falsch in Erinnerung?

Egal, wie dem auch sei: die seltenen Gelegenheiten, in denen ich Code 
von einer Datei in eine andere kopiere oder verschiebe, reichen mir bei 
Weitem nicht aus, um mich an der Sache mit dem Whitespace in Python zu 
stoßen. Da sehe ich dann letztlich dennoch mehr Vor- als Nachteile.

> Und besser
> lesbar ist Code mit einer gewissen Redundanz ohnehin – siehe Leerzeichen
> innerhalb von Ausdrücken.

Da geht es aber um Abgrenzung und nicht um Redundanz, oder?

Wie auch immer: die Geschichte mit dem Whitespace in Python muß man 
nicht gut finden, auch wenn ich es tue. Aber das ändert ja nichts daran, 
daß man damit gut leben und arbeiten, und mit Python sehr schnell 
überaus leistungsfähige Programme entwickeln kann, auch für numerische 
Berechnungen -- um mal wieder auf das Thema dieses Threads 
zurückzukommen.

von Ein T. (ein_typ)


Lesenswert?

Jörg W. schrieb:
> Norbert schrieb:
>> Diese ganze Einrücken-ist-schlecht Diskussion bei Python ist so dermaßen
>> überflüssig, dass es der Sau graust!
>
> Klar: diese Sprache ändert eh keiner mehr. ;-)

Bython [1] existiert. :-)

[1] https://github.com/mathialo/bython

von Norbert (der_norbert)


Lesenswert?

Jörg W. schrieb:
> Bei mir sind es keine Vorbehalte, sondern durchaus die Erfahrungen
> damit. Dabei ist Python wohl die Sprache, in der ich in den letzten
> Jahren (vor allem beruflich) am meisten programmiert habe. Ich weiß also
> durchaus, wovon ich schreibe, und nur weil ich einzelne Aspekte
> kritisiere heißt das nicht, dass ich diese Sprache jetzt insgesamt
> unbenutzbar fände.

Darum ging es in meiner Antwort überhaupt nicht.
Es ging darum, dass hier wirklich überflüssige Kleinigkeiten in einer 
überzogenen Weise herangezogen werden, um eine komplette 
Programmiersprache zu bewerten. (Ob nun positiv oder negativ sei mal 
dahin gestellt)

Ob's nun die Geschwätzigkeit von Pascal ist, das Ausrufezeichen bei C, 
ternäre Ops, oder was es sonst noch alles an Diskussionsmaterial gibt…

Es wird alles bis zur Unkenntlichkeit aufgeblasen und alle vielleicht 
noch als vernünftig anzusehenden Argumente ad absurdum geführt.

Nur damit mal der eine, dann der andere und dann der dritte irgendwie 
seine Befriedigung bekommt, Recht zu haben (oder es zumindest zu meinen 
oder zu glauben)

von Re D. (re_d228)


Lesenswert?

Jörg W. schrieb:
> siehe Leerzeichen innerhalb von Ausdrücken.

Auch wenn du es 3 mal wiederholst, ein Leerzeichen ist keine Redundanz, 
genauso wenig wie eine ordentliche Variablenbezeichnung. Deine 
vergleiche hinken nicht nur, die sitzen im Rollstuhl.

Jörg W. schrieb:
> Die Redundanz von {} oder begin … end bringt es nämlich mit sich, dass
> man beispielsweise nach einer größeren copy&paste-Aktion den Code
> automatisch durch eine Maschine neu sortieren lassen kann. Und besser
> lesbar ist Code mit einer gewissen Redundanz ohnehin – siehe Leerzeichen
> innerhalb von Ausdrücken.

Und wenn du den coursor falsch vor einer Klammer positioniert hat?

von Rbx (rcx)


Lesenswert?

Norbert schrieb:
> Es ging darum, dass hier wirklich überflüssige Kleinigkeiten in einer
> überzogenen Weise herangezogen werden, um eine komplette
> Programmiersprache zu bewerten.

Wenn man sich den Code im Hexeditor ansieht, interessiert das eh kaum 
noch.
Das ist eine Kunst, die kaum gefördert wird.
Bei Webseiten konnte man früher noch gut den Code nachvollziehen, bei 
aktuellen Webseiten braucht man aber schon gute Lesehilfen.

Interessant ist bei Haskell, dass die Programmiersprache unglaublich gut 
ausbalanciert ist, und so sieht man (dank vieler Sprachzucker-Goodies) 
auch kaum so viele Klammern wie bei Lisp oder Closure.
Was natürlich wirklich fehlt bei Haskell, dass kein Zugang für 
Hardware-Tuning da ist. Gut, man kann nicht alles haben. Dafür ist 
Haskell auf der anderen Seite richtig gut für Parallel-Programme.
Und gerade, wenn es um Parallelisierung geht, kann man auf Haskell 
setzen, nur schade, dass der Hype vorbei ist, der Code so fremdartig und 
die Bibs wenig praxistauglich.
Das heißt, bei Haskell gibt es schon einige größere Angriffsflächen für 
Optimierung.

So ein paar grundlegende Infos zu C++ Optimierung gibt es hier und da 
auch noch, aber ich glaube, früher gab es davon noch mehr, im Moment 
werden Online viel Bücher zu C++ Optimierung in den Suchmaschinen 
vorgeschlagen.
https://quantumzeitgeist.com/c-high-performance-computing/

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Re D. schrieb:
> Und wenn du den coursor falsch vor einer Klammer positioniert hat?

Ist doch egal, du kannst die Einrückungen für völlig beliebige Bereiche 
neu berechnen lassen, bis hin zur ganzen Datei (ganz früher gern mit 
indent(1) so gemacht worden). Auf den Cursor kommt es nicht an.

Ein T. schrieb:
> Reden wir gerade von Les- und Wartbarkeit, oder von Kopierbarkeit?

Beides möchte ich haben.

Solche Kopierorgien entstehen beispielsweise, wenn man irgendwo merkt, 
dass die Verschachtelungstiefe zu groß wird und man lieber Teile als 
separate Funktion auskoppeln will. Solange das ein einziger Block ist, 
klappt das in der Tat mit den von dir genannten Emacs-Funktionen, aber 
wenn es von mehreren Stellen zu verschieben ist, dann landet man schnell 
an einem Punkt, an dem man anfängt, die gesamte (eigentlich bereits 
getestete) Logik in der Kopie nachzuvollziehen, um die korrekte 
Einrückung zu finden. Bei einer Sprache, die andere syntaktische 
Elemente für die Gruppierung benutzt, kann dagegen eine Maschine immer 
die passenden Einrückungen selbst berechnen, denn sie muss die Logik 
dahinter nicht nachvollziehen.

Ein T. schrieb:
> Wie auch immer: die Geschichte mit dem Whitespace in Python muß man
> nicht gut finden, auch wenn ich es tue. Aber das ändert ja nichts daran,
> daß man damit gut leben und arbeiten, und mit Python sehr schnell
> überaus leistungsfähige Programme entwickeln kann, auch für numerische
> Berechnungen -- um mal wieder auf das Thema dieses Threads
> zurückzukommen.

Ich gehöre zwar zu denen, die sie nicht gut finden, stimme aber mit dem 
Rest deiner Ausführungen ganz genauso überein.

von Re D. (re_d228)


Lesenswert?

Jörg W. schrieb:
> Ist doch egal, du kannst die Einrückungen für völlig beliebige Bereiche
> neu berechnen lassen, bis hin zur ganzen Datei (ganz früher gern mit
> indent(1) so gemacht worden). Auf den Cursor kommt es nicht an.

Du hast das Problem nicht verstanden. Und im übrigen, ein guter Struktur 
in Programm braucht keine 3 Verschlechterungen.

von M.A. S. (mse2)


Lesenswert?

Jörg W. schrieb:
> Solche Kopierorgien entstehen beispielsweise, wenn man irgendwo merkt,
> dass die Verschachtelungstiefe zu groß wird und man lieber Teile als
> separate Funktion auskoppeln will.
Hat Deine IDE keine Refactoring-Funktionen?
Ich programmiere Python unter Visual Studio Code, da kann man sowas 
machen:
Refactor, extract Method.

von M.A. S. (mse2)


Lesenswert?

Re D. schrieb:
> 3 Verschlechterungen.
3 Verschlechterungen braucht niemand.  :D

von Vanye R. (vanye_rijan)


Lesenswert?

> Aber wenn wir unseren Code ohnehin korrekt einrücken, sind die {, },
> begin und end schlicht und ergreifend: redundant,

Nein, es ist Unsinn weil mein "einruecken" sicher ein anderes sein wird 
wie deines. Und ich plane nicht mich an einem Computer anzupassen 
sondern erwarte es anders rum!

Vanye

von Ein T. (ein_typ)


Lesenswert?

Vanye R. schrieb:
> Nein, es ist Unsinn weil mein "einruecken" sicher ein anderes sein wird
> wie deines.

Kannst Du machen, is dann halt Kacke.

> Und ich plane nicht mich an einem Computer anzupassen
> sondern erwarte es anders rum!

Dann schreibst Du keinen Code.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Ein T. schrieb:
> Dann schreibst Du keinen Code.

Das ist 'ne blöde Unterstellung.

Du weißt ganz genau, dass es durchaus sehr viele verschiedene 
Einrückungs-Stile gab und gibt. Jedes Projekt hat da andere Vorlieben. 
Trotzdem sind sie deshalb alle in sich konsistent und leiden nicht unter 
dem immer wieder behaupteten "das sei unleserlich und unübersichtlich". 
Ich habe in meinem Leben an so vielen verschiedenen Dingen 
mitgearbeitet, dass ich gar kein Problem habe, mich (bzw. meinen Editor) 
an den jeweiligen Stil des Projekts anzupassen.

von Re D. (re_d228)


Lesenswert?

Jörg W. schrieb:
> Ein T. schrieb:
>> Dann schreibst Du keinen Code.
>
> Das ist 'ne blöde Unterstellung.

Denk noch mal drüber nach:

Ein T. schrieb:
>> Und ich plane nicht mich an einem Computer anzupassen
>> sondern erwarte es anders rum!
>
> Dann schreibst Du keinen Code.

Ist nicht so schwer zu verstehen, was Ein T. meint oder? Oder passt sich 
dein Compiler an dich an?

Jörg W. schrieb:
> verschiedene Einrückungs-Stile gab und gibt.

Bei Python gibt es eine PEP.

Jörg W. schrieb:
> Ich habe in meinem Leben an so vielen verschiedenen Dingen
> mitgearbeitet, dass ich gar kein Problem habe, mich (bzw. meinen Editor)
> an den jeweiligen Stil des Projekts anzupassen.

Du nicht, Vayne scheinbar schon. Der will seine Einrückung.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Re D. schrieb:
>> verschiedene Einrückungs-Stile gab und gibt.
>
> Bei Python gibt es eine PEP.

Dass man einem Programmierer mit der Syntax auch gleich noch den Stil 
diktiert, kann man aber eben durchaus als übergriffig betrachten.

von Norbert (der_norbert)


Lesenswert?

Jörg W. schrieb:
> Dass man einem Programmierer mit der Syntax auch gleich noch den Stil
> diktiert, kann man aber eben durchaus als übergriffig betrachten.

Dir ist aber schon klar dass das zweite ›P‹ für proposal steht?

Mein Kommentar weiter oben scheint seine Gültigkeit zu behalten.

von Re D. (re_d228)


Lesenswert?

Jörg W. schrieb:
> Dass man einem Programmierer mit der Syntax auch gleich noch den Stil
> diktiert, kann man aber eben durchaus als übergriffig betrachten.

Jo, ich fühle mich von DIN A4 auch im meiner künstlerischen Freiheit 
eingeschränkt.

von Yalu X. (yalu) (Moderator)


Lesenswert?

PEP 8 ist halt ein Style-Guide. Er ist nur dann bindend, wenn man in
einer Entwicklergruppe arbeitet, die auf dessen Einhaltung besteht. Das
ist nicht anders als bei den mannigfaltigen Style-Guides für C, C++,
Java usw.

Ich persöönlich finde bspw. die im PEP empfohlene Einrückungstiefe von 4
Spaces/Level als übertrieben und verwende stattdessen nur 2 Spaces. Wenn
ich mit Leuten zusammenarbeite, die 4 Spaces bevorzugen, passe ich mich
entsprechend an. Bereits bestehender Code ist schnell mit reindent.py
auf 4 Spaces umgestellt.

von Rbx (rcx)


Lesenswert?

Ein T. schrieb:
> Kannst Du machen, is dann halt Kacke.
Quark
(Inwiefern denn überhaupt??)

Ein T. schrieb:
> Dann schreibst Du keinen Code.

Da haben wir es wieder: die Persönlichkeitsebene, nur grob 
holzschnittartig angepeilt und schon wieder herumstreiten.

Bei Fortran 77 muss man auch auf die gezählte Position achten. Sollte 
man mal ausprobieren, wenn man das nicht kennt.
(kann man aber auch nachlesen, falls keine Lust drauf: 
https://web.stanford.edu/class/me200c/tutorial_77/03_basics.html)

Und dann: Doppeldeutigkeit.. Auf jeden Fall ähneln sich ja (auch) (z.B.) 
Python und der Emacs in gewisser Weise.

Ist halt viel Automagie mit im Spiel, und dann kann man natürlich schön 
drumherum blubbern, als gäbe es die nicht.
Im Hexeditor dagegen muss man auch wieder zählen.

Hm, und Java? Soll ja "plattformunabhängig" sein. Theoretisch ja, wenn 
man darüber hinwegsieht, dass es riesige (nix für Speichersparer) 
Runtime-Dateien für die passende Hardware-Plattform braucht.

Und für Teams gibt es ja auch meist Code-Style-Pläne, was gar nicht 
ginge, wenn alles wie beim Hexeditor vorgegeben ist.

https://www.w3schools.com/python/python_lists_comprehension.asp
https://www.haskell.org (die übliche List Comprehension auf der Seite 
oben rechts)
(wenn man die mathematischen Mengentechnischen Hintergründe vor Augen 
hat, fällt es wohl leichter, den Code nachzuvollziehen.)
https://stackoverflow.com/questions/51775829/how-to-use-list-comprehension-in-haskell

Vieles ist auch einfach eine Übungsfrage wo gar nicht so genau klar ist, 
wer sich jetzt an wen anpasst ;)

(Wer "App" sagt, hat sich auf jeden Fall schon mal an den Java Jargon 
angepasst. :D )

von Rbx (rcx)


Lesenswert?

Re D. schrieb:
> Jo, ich fühle mich von DIN A4 auch im meiner künstlerischen Freiheit
> eingeschränkt.

Das ist auch was Doppeldeutiges, weil vor allem leere Seiten (kariert 
oder nicht) erstmal zu gar nix inspirieren.
Das muss man überwinden können.

von Ein T. (ein_typ)


Lesenswert?

Jörg W. schrieb:
> Du weißt ganz genau, dass es durchaus sehr viele verschiedene
> Einrückungs-Stile gab und gibt. Jedes Projekt hat da andere Vorlieben.

Richtig, und deswegen passe ich meinen Code natürlich auch den Vorlieben 
des Projekts an. Ich weiß nämlich auch, wie unfaßbar nervig und 
aufwändig es ist, mit Diven, Besserwissern und Querulanten zu arbeiten, 
die solche Dinge nur aus einem einzigen Grund anders machen: um der 
kleine große Held zu sein, der sich "von nichts und niemandem was 
vorschreiben" läßt.

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.