Python ist keine geeignete Sprache für Data Science

• Bei Nicht-Deep-Learning-Datenaufgaben wie Datenanalyse, Visualisierung und Zusammenfassung bietet Python zwar genügend Funktionen, aber die Nutzererfahrung wird leicht komplex und ineffizient
• In zahlreichen Beispielen aus dem Labor zeigte sich wiederholt die Tendenz, dass Python selbst für einfache Diagrammtransformationen und statistische Berechnungen mehr Code und Zeit als R erfordert
• Selbst mit pandas, matplotlib und NumPy führen Syntax, Indexing, Klammern und Method-Chain-Strukturen oft dazu, dass man eher von Implementierungsdetails (Logistik) als von der eigentlichen Logik gefesselt wird
• Im Gegensatz dazu kann R mit tidyverse Datenverarbeitungsabläufe auf nahezu natürlichem Sprachniveau ausdrücken, sodass sich die Arbeitslogik leicht direkt in Code übertragen lässt
• Python hat als Data-Science-Sprache strukturelle Grenzen bei der Trennung von Logik und Logistik, und dieses Problem geht auf das Design der Sprache und ihres Ökosystems zurück

---

Vergleich der tatsächlichen Nutzungserfahrung mit Python und R

• Mitglieder des Labors können ihre Sprache frei wählen, doch viele nutzen Python, und es zeigt sich durchgängig ein Muster, dass sie einfache zusätzliche Analyseanfragen nicht schnell erledigen können
  • Selbst Visualisierungswechsel wie Boxplot → Violinplot, Histogramm → Dichteplot oder Liniendiagramm → Heatmap lassen sich nicht sofort umsetzen
  • Was in R in wenigen Zeilen erledigt ist, fühlt sich in Python oft so an, als müsse man „an den Platz zurückkehren und neu coden“
• Auch bei gemeinsam mit Python-Experten durchgeführten Kursen zeigte sich ein großer Unterschied zu R bei der benötigten Codelänge und Komplexität
  • Die Reaktion „Warum muss das so kompliziert sein?“ trat in vielen Situationen wiederholt auf; das wirkt nicht wie ein Problem individueller Fähigkeiten, sondern wie ein struktureller Unterschied in der Architektur von Sprache und Bibliotheken
  • Selbst bei identischer Logik sind in Python Indexing, Datentrennung, Neu-Zusammenbau und die Kombination mehrerer Methoden nötig, wodurch die Struktur weitschweifig wird
  • R tidyverse erlaubt eine direkte Ausdrucksweise mit natürlichen Chains wie filter → group_by → summarize

Warum Python weit verbreitet ist — und seine Grenzen

• Der Status von Python in Data Science beruht eher auf historischer Verbreitung, Allgemeinverwendbarkeit und der Größe des Ökosystems als auf einer einzigartigen Eignung
  • Im Deep-Learning-Bereich ist Python dank PyTorch und dem AI-Ökosystem klar das Zentrum
  • Bei Datenbereinigung, Exploration, Visualisierung und statistischer Modellierung bleibt es jedoch häufig umständlich
• Es handelt sich um eine Popularität, die „eher einem historischen Zufall (historical accident)“ gleicht, und die schwerfällige Sprachstruktur im Vergleich zu R zeigt sich in vielen Beispielen immer wieder

Voraussetzungen für eine gute Data-Science-Sprache

• Für Aufgaben mit Fokus auf Datenexploration, Zusammenfassung, Modellanpassung und Visualisierung sind interaktive Umgebungen, geringe Einrichtungsaufwände und schnelle Iteration am wichtigsten
  • Dafür eignen sich skriptbasierte Interpretersprachen besser als kompilierte Sprachen
  • Wichtiger als Performance sind einfacher Code, geringeres Fehlerrisiko und minimale kognitive Belastung
  • Falls nötig, reicht es aus, nicht den gesamten Code, sondern nur einzelne Operationen in einer Hochleistungssprache wie Rust neu zu schreiben
• Realistisch betrachtet kommen R und Python infrage
  • Matlab, Mathematica und ähnliche Werkzeuge sind kommerziell oder haben ein begrenztes Ökosystem
  • Julia wird oft erwähnt, doch der Autor hat sie nicht ausreichend genutzt und enthält sich daher eines Urteils

Das Problem „Logik vs. Logistik“

• Eine Sprache für Datenanalyse sollte trennen, was berechnet werden soll (Logik), und wie es berechnet wird (Logistik)
  • Wenn man auf Datentypen, Indizes, Loops und manuelle Zusammensetzung achten muss, ist man bereits in der Logistik gefangen
• Im Palmer-Penguins-Beispiel drückt R tidyverse die Berechnung von Mittelwert und Standardabweichung in einem nahezu natürlichsprachlichen Ablauf aus
  • Es ist nicht nötig, den Datenfluss zu zerlegen und anschließend wieder zusammenzubauen
• pandas bietet ähnliche Funktionen, aber String-Angaben, Klammern, Method-Chains und Zusatzschritte wie reset_index mindern Lesbarkeit und Einfachheit
• Wenn man dieselbe Aufgabe nur mit reinem Python implementiert
  • Loop-Struktur aufbauen → Gruppenschlüssel erzeugen → aufteilen → Mittelwert berechnen → Varianz berechnen → Standardabweichung berechnen → wieder zusammensetzen → sortieren usw.
  • Alles muss manuell verarbeitet werden, was zu einem typischen Fall führt, in dem der Logistik-Code die Logik überwältigt

Fazit und Ausblick auf die folgenden Inhalte

• Python zeigt in der Datenanalyse wiederholt ein strukturelles Problem, das dazu führt, dass man sich stärker auf Implementierungsdetails als auf Logik konzentriert
  • Das scheint das Ergebnis einer Kombination aus Eigenschaften der Sprache selbst, Grenzen des Bibliotheksdesigns und Konventionen im gesamten Ökosystem zu sein
• In einem Folgebeitrag sollen die konkreten technischen Ursachen behandelt werden, die Datenanalyse in Python schwieriger machen als in R

Zusätzliche Diskussionen und Vergleichsperspektiven (einschließlich Leserfeedback)

• Einige meinen, tidyverse könne ausführlicher sein als Base R, sei aber in Bezug auf Ausdruckskraft, Konsistenz und Abstraktion der Datenverarbeitung sehr stark
• Andererseits wird eingewandt, dass R aus Sicht der Softwareentwicklung bei Modularisierung, Tests und CLI-Implementierung große Nachteile habe
• Python bietet eine starke Developer Experience bei Logging, virtuellen Umgebungen, Packaging und Klassenstrukturen, aber
  • matplotlib hat ein nicht intuitives Design,
  • pandas eine inkonsistente Syntax,
  • und bei scikit-learn werden Designprobleme häufig erwähnt
• Manche Stimmen sehen Python als eine „Sprache, mit der sich instabiler und qualitativ schlechter Code schnell in großen Mengen produzieren lässt“, und merken an, dass für nachhaltige Entwicklung statisch typisierte Sprachen besser geeignet seien

[kaydash]

Wenn die Komplexität und Menge der Daten zunimmt, eine schrittweise Aufteilung der Verarbeitung nötig wird und zudem unstrukturierte Daten, strukturierte Modelle sowie die Aufbereitung über LLMs erforderlich sind, gibt es viele Use Cases – ist es dann nicht gerade die am besten geeignete Sprache?

[GN⁺]

Hacker-News-Kommentare

• Es wurden verschiedene Transformationsbeispiele genannt, etwa boxplot zu violin plot oder line plot zu heatmap.
  Diese Diskussion betrifft in Wirklichkeit eher matplotlib als Python selbst.
  Wer das Design von ggplot in Python möchte, kann einfach plotnine verwenden.
  Dass R-Code kompakter wirkt, liegt an der nichtstandardmäßigen Auswertung (non-standard evaluation) in R.
  Python erlaubt solche Erweiterungen nicht auf Sprachebene.
  Siehe dazu auch Computing on the language

  • Letztlich geht es hier um die Unterschiede zwischen Python und R.
    Nichtstandardmäßige Auswertung ist in interaktiven Umgebungen praktisch, wird aber beim Schreiben komplexer Analyseprogramme eher zum Nachteil.
    Selbst einfache Aufgaben müssen dann manchmal auf Umwegen gelöst werden.
  • In R-Code am Satzende platzierte Pipes sind schwer anzusehen.
    Wie in Elixir wäre ein vorn stehender Pipe-Operator aus meiner Sicht besser.
    Auch Python kann mit Tricks wie getattr eine ähnliche Syntax nachahmen, aber am Ende ist das eher eine Frage des Library-API-Designs als der Sprache selbst.
  • „Wie wäre es, logistische Arbeit in R ohne Libraries zu machen?“ Schon die Vorstellung ist furchtbar.
    R ist nur dann einfach, wenn es Libraries und Rezepte gibt; ohne sie ist es wirklich schwierig, und meistens macht man es dann einfach nicht.
  • Für diesen Zweck ist seaborn passend.
    Es abstrahiert die Unbequemlichkeiten von matplotlib und bietet trotzdem umfangreiche Funktionen.
    Seaborn-Tutorial
  • Am Ende scheint der Kernpunkt nicht Python zu sein, sondern eher das, was R kann und Python nicht.

• Ich frage mich, warum Tabellen in Programmiersprachen keine Objekte erster Klasse sind.
  In den meisten Sprachen muss man zum Arbeiten mit Tabellen separate APIs wie pandas oder polars lernen.
  In R kommt data.frame einem Objekt erster Klasse nahe, in der Praxis wird aber häufiger das tibble aus dplyr verwendet.
  Eine Ausdruckssprache für tabellarische Daten ist noch immer nicht standardisiert.
  Polars und dplyr teilen eine ähnliche Philosophie, aber am Ende scheint SQL die einzige gemeinsame Grundlage zu sein.
  Python ist nicht perfekt, aber R aus meiner Sicht ebenso wenig.

  • Es fühlt sich an, als würden auf Sprachebene viele Strukturen fehlen.
    Strukturen wie Tabellen, Matrizen, Graphen und Zustandsautomaten werden nicht auf Sprachebene unterstützt, was ihren Einsatz einschränkt.
    Die Werkzeuge, die eine Sprache standardmäßig mitbringt, bestimmen den „schönen Weg“ dieser Sprache.
    Früher waren selbst Key-Value-Stores externe Libraries, heute gelten sie fast als Standard.
  • Sprachen wie Q, Rye und Lil behandeln Tabellen als echten Datentyp erster Klasse.
    Ich erwarte, dass Mainstream-Sprachen irgendwann eine solche tabellenbasierte Programmierung übernehmen werden.
    Q-Sprache, Vergleich zu Rye, Lil-Experimentierwerkzeug
  • tibble und data.table erben von data.frame, daher funktionieren die Basisfunktionen von R unverändert weiter.
    Auch die Umwandlung zwischen diesen drei Objekten ist sehr einfach.
  • Wenn Tabellen von 1 Million auf 1 Milliarde oder 1 Billion Zeilen wachsen, ändert sich die Natur des Problems vollständig.
    Eine Standard-API zu entwerfen, die solche Größenunterschiede elegant behandelt, ist nicht einfach.
  • Das data.table von R ist hervorragend.
    Allerdings hat dplyr bei Dokumentation und Onboarding gewonnen und dadurch Akzeptanz in der Industrie erreicht.

• Die Kernaussage des Artikels ist in Ordnung, aber schade, dass der Autor seine Begründung zu früh offenlegt.
  R ist stark bei der Verarbeitung von Data Frames, aber schwach bei Dateiverwaltung und Wartbarkeit.
  Wenn solche Arbeiten häufig anfallen, ist Python die bessere Wahl, und wenn zusätzlich Geschwindigkeit wichtig ist, tendiert man eher zu Julia.
  Die Wahl der Sprache hängt letztlich von den Prioritäten ab.
  Ich sehe oft Studierende, die mit pandas nichttabellarische Probleme wie Graphen lösen wollen; in solchen Fällen sollte man die Werkzeugwahl noch einmal überdenken.

  • Das Python-Beispiel ist unpassend.
    Mit numpy sind Berechnungen von Mittelwert und Varianz bereits eingebaut.
    Python und R sind beide ähnlich schwer zu lernen, aber Python hat seine Stärke in der Integration mit anderen Anwendungen.
  • Den zweiten Teil des Artikels gibt es hier.
  • Ich verwende Python und R ungefähr je zur Hälfte.
    Für die Verarbeitung großer Dateien nutze ich Python, für die Analyse zusammengefasster Daten ist R effizienter.
    Beide Sprachen sollte man als Werkzeuge für den jeweils passenden Zweck einsetzen.

• Als Python-Programmierer habe ich auch R verwendet, und Python ist eine „Sprache, die fast alles ziemlich gut kann, aber nichts perfekt“.
  Wenn man den ganzen Tag Datenanalyse macht, sollte man R lernen.
  R ist eine Sprache, die auf die Denkweise von Statistikern zugeschnitten ist.
  Anfangs wirkt das ungewohnt, aber genau dieser Perspektivwechsel hilft auch.
  Trotzdem arbeite ich die meiste Zeit in Python.

• Data Science mit pandas ist möglich, wirkte auf mich aber grob und komplex.
  Mit polars wurde es etwas besser, aber mit duckdb hat sich alles völlig verändert.
  Ich führe SQL-Abfragen direkt im Notebook aus und analysiere Parquet-Dateien.
  Wenn man SQL-Zellen und Python-Zellen mischt, wird der Code sauberer.
  Beim letzten Vergleich Python vs. R im Artikel dachte ich nur: „Wäre das nicht in SQL deutlich besser?“

  • Ich bevorzuge gegenüber SQL eher einen Data-Frame-zentrierten Ansatz, bei dem alles innerhalb der Sprache bleibt.
  • Ich nutze oft polars, sollte duckdb aber auch einmal ausprobieren.

• Das letzte Python-Beispiel ist unnötig weitschweifig.
  Mit defaultdict und statistics.stddev wäre es deutlich kürzer.

  • Interessant ist, dass die Bessel-Korrektur von Hand eingebaut wurde.
    Oft wird so etwas implementiert, ohne zu prüfen, ob die Korrektur überhaupt sinnvoll ist.
    Eigentlich müsste das korrekt sample_std_dev heißen.
  • Man könnte auch itertools.groupby verwenden.
    Der Code wäre nicht kürzer, könnte aber die Absicht klarer ausdrücken.
  • Der ursprüngliche Code ist besser lesbar.
    Nur um ihn kürzer zu machen, Lesbarkeit zu opfern, ist keine gute Idee.

• Ich habe dasselbe Beispiel mit TidierData.jl in Julia umgesetzt, und das Ergebnis ist nahezu identisch mit der R-Version.
  Die Makro-Syntax mit @chain, @group_by und @summarize ähnelt dem tidyverse von R.

• Ich verstehe die Unzufriedenheit des Autors nicht ganz.
  Dass Python nicht für Data Science optimiert ist, ist doch offensichtlich.
  Python ist keine DSL, und selbst MATLAB, das für wissenschaftliches Rechnen entworfen wurde, ist keine besonders beliebte Sprache.
  Eine gute Sprache ist eher wie eine lebenswerte Stadt als wie perfektes Wetter.
  Python ist wie „eine nordische Stadt, in der das Wetter mäßig ist, die aber floriert“.
  Das Thema des Artikels wirkt etwas klickorientiert und führt aus meiner Sicht nicht zu einer besonders produktiven Diskussion.

• Ich wünschte, Julia würde häufiger eingesetzt.
  Ich habe einmal einen Algorithmus aus einer psychometrischen Facharbeit in Julia neu implementiert, und er lief dreimal schneller als in MATLAB.
  Link zum Artikel

  • Ich frage mich, wie wichtig diese eingesparten 40 Minuten Laufzeit für den gesamten Zeitplan der Arbeit tatsächlich waren.

• Das letzte Beispiel wirkt weniger wie realistischer Python-Code, sondern eher wie eine Anti-Python-Satire.
  Die Standardabweichung von Hand zu implementieren, ist eher Stoff für eine Übung im Grundstudium.
  In der Praxis laufen intern sowohl in R als auch in Python solche Schleifen.

  • Ich verstehe, dass sich der Artikel auf den Kontext von Forschungslaboren konzentriert.
    In realen Industrieumgebungen ist Python aber deutlich einfacher für die Zusammenarbeit mit Engineering-Teams.
    Ich habe einmal R-Code in Produktion ausgerollt, und das war sehr instabil.
    Für explorative Datenanalyse (EDA) ist R hervorragend, aber für groß angelegte Softwareentwicklung ungeeignet.