Zur Zeit versuche ich zu erheben, welche Qualität in der Bioinformatik publizierte Software tatsächlich hat. Rein subjektiv hat sich in den letzten 10 Jahren wenig verändert. Das ich meine Zweifel habe, ob die Qualität gut ist, dürfte Euch schon aufgefallen sein (ich denke nicht, dass alles schlecht ist!). Andere haben prinzipielle Bedenken, in Hinblick auf die Qualität wissenschaftlicher Software. Doch behaupten kann man viel. Es gilt erst einmal Daten zu sammeln.

Zum Glück haben das Andere zu einem Teilaspekt schon getan. In diesem, etwas längeren, Artikel möchte ich das aufgreifen. Achtung: Es können hier nicht alle wichtigen Aspekte berücksichtigt werden. Bitte berücksichtigt das in der Diskussion.

Noch eine Kleinigkeit vorweg

Ab und an halte ich Kurse zur Nutzung unserer Cluster. Manche der Teilnehmenden (Studierende ab Bachelor- oder Masterniveau, DoktorandInnen, PostDocs, GastwissenschaftlerInnen, ProfessorInnen, etc. – aus allen Fachbereichen), wissen bis zu dem Zeitpunkt nicht, was ein “Compiler” eigentlich ist. Da stelle mer uns jetzt janz dumm, und sagen so: Ein Compiler, das ist ein Programm, dass Code in (hoffentlich) optimierte Befehle für einen Computer verständlich übersetzt, so dass ein ausführbares Programm herauskommt. Interpreter sind eigentlich ganz ähnlich wie Compiler: Sie legen den Programmtext nicht übersetzt ab (als “Programm”), sondern interpretieren bei jeder Ausführung aufs Neue. — Das soll erst einmal reichen. Wenn Interesse besteht kann ich mal mehr über die Funktionsweise von Compilern oder Interpretern schreiben (aber irgendwie denke ich das ist Teil des Informatikstudiums und wird wenige interessieren).

Doch was ist der Unterschied?

Erst einmal: Kompilierte* Programme können prinzipiell schnellere Ausführung garantieren als interpretierte Programme (oft auch Skripte genannt), weil die Compiler ja a) bereits für den Computer übersetzt haben und b) auch in der Lage sind manche Optimierungen während des Kompilierschrittes einzubringen. Interpreter kennen für diesen Zweck just in time compiler, diese übersetzen und optimieren das Programm (oft auch nur Teile) zur Laufzeit. Theoretisch benötigt ein kompiliertes Programm auch weniger Arbeitsspeicher als eine gleichförmige Lösung, die für einen Interpreter geschrieben wurde: Der Interpreter benötigt an sich schon Speicherplatz und die internen Datenstrukturen sind oft komplexer, während die kompilierten Sprachen sehr genaue Kontrolle über den Speicher erlauben.

Interpretierte Sprachen sind nicht nur in der Bioinformatik, nicht nur irgendwo in der wissenschaftlichen Programmierung, sondern allgemein beliebt. Ein Grund ist der read-eval-print loop (REPL): Man kann interaktiv programmieren und sieht das Ergebnis unmittelbar, ohne jedenfalls den Umweg über einen Compiler. Hinzu kommt im wissenschaftlichen Bereich, dass interpretierte Sprachen i. d. R. auch Bibliotheken an Bord haben, die gute wissenschaftliche Darstellungen (auch “Plots”) ermöglichen. Und Visualisierung ist wichtig!

Wie wirkt sich das im wissenschaftlichen Alltag aus?

Mir geht es um die Qualität wissenschaftlicher Software, insbesondere in der Bioinformatik, da kann ich meinen Vergleich auf die beliebtesten Sprachen in der Bioinformatik beschränken:

Interpretierte Sprachen, also Programmiersprachen, die ein Interpreter zur Ausführung gegeben werden, sind u. a.:

Compilierte Sprachen, also Programmiersprachen, deren Code erst durch einen Compiler übersetzt werden muss, um ein ausführbares Programm zu erhalten, sind u. a.:

  • C
  • C++
  • und seid Neustem gehört auch Rust in die Liste der beliebteren Sprachen in der Bioinformatik, aber da weiß ich nicht, ob der Trend anhalten wird.

Vielleicht kennt Ihr die eine oder andere Sprache und fragt: Und die Shell, z. B. bash? Die ist fraglos wichtig – auf Anwender und Entwicklerseite, aber darin werden keine Anwenderprogramme für WissenschaftlerInnen geschrieben. Und Java? Ist irgendwie ein Zwitter: Mit Aufkommen des “just in time” Compilers in der Java-Virtual Machine (VM) wird nicht mehr “nur” interpretiert, doch andererseits gibt es kein ohne Java-VM ausführbares Programm. Die Veröffentlichung, auf die ich mich beziehe, hatte das Ziel Programmiersprachen in der Bioinformatik zu vergleichen. Sie ist immerhin schon 10 Jahre alt und listet zusätzlich C#, aber die Sprache ist mir egal, weil ich unter Linux arbeite (HPC cluster arbeiten z. Zt. ausschließlich unter Linux und zusätzliche Laufzeitumgebungen, wie mono, machen die Software nicht schneller oder leichter zu nutzen). Und Rust nicht nicht aufgeführt, man kann nicht alles haben. (Wenn jemand eine aktuellere / bessere Veröffentlichung kennt: Her damit!) Hierbei greife ich mal zwei Abbildungen heraus:

Geschwindigkeitsvergleich bei einem globalem Alignment; es werden also die Geschwindigkeiten bei einer Aufgabe verglichen, die in der Bioinformatik häufig vorkommt. Die Autoren geben an, stets gleichförmig implementiert zu haben. Lizenz: CC BY 4.0

Zwei Dinge werden unmittelbar deutlich:

  1. die beiden interpretierten Sprachen (Perl und Python) lösen das Problem deutlich langsamer als die anderen Sprachen.
  2. Linux scheidet konsequent schlechter ab.

Und weiter:

 

Die zweite Abbildung zeigt die Spitzen des Speicherverbrauchs beim gleichen Problem “Alignment” und bei einem bestimmten Gruppierungsverfahren. Lizenz: CC BY 4.0

Auch hier sieht man: Die interpretierten Sprachen benötigen deutlich mehr Speicher.

Über Benchmarks

Ein Disclaimer: Das Bonmot “Traue keiner Statistik, die Du nicht selber …” kennen wir alle. Bei Benchmarks, also dem systematischen Vergleich zwischen Programmen, Algorithmen, Implementierungen (also Umsetzungen in “Code”), usw. oder eben Programmiersprachen, verhält es sich ähnlich: Sie wecken schnell inneren Widerstand, weil schnell Gedanken aufkommen wie “die Leute haben X nicht berücksichtigt oder Y falsch gemacht”. Das liegt daran, dass eigene Erfahrungen und Wunschvorstellungen den Befunden häufig widersprechen. Womöglich ist der ein bestimmter Benchmark wirklich nicht gut. Aber man kann ja dennoch etwas daraus lernen.

Also weiter …

Der Vergleich “schummelt” ein wenig. Das Problem ist natürlich die Umsetzung: Wenn ich eine Aufgabe in Sprache X gut und in Y naiv umsetze, schneidet Y im Vergleich schlechter ab. Gute Programmiersprachenvergleiche setzen daher auf Streuung: Mehr ProgrammiererInnen, die sich jeweils eine Sprache, in der sie sich gut fühlen auswählen und damit Lösungen erstellen. Und solche Vergleiche sind deutlich differenzierter. Die Autoren obiger Veröffentlichung schreiben “All the programs examined here were written by the same programmer with different levels of experience in Java, Perl and C++. The other languages were implemented while learning them. …”. Da kann und sollte man Fragezeichen hinter manche Details setzen. Aber der allgemeine Trend — kompilierte Sprachen schnell, interpretierte langsamer und speicherhungrig — ist dadurch (für mich) nicht in Zweifel gezogen und ich finde das gerade auch nicht so wichtig: Mir geht es darum Unterschiede bei alltagsnahen Problemen aufzuzeigen – also alltagstauglich für programmierende BioinformatikerInnen. Und zu diskutieren.

Meine Erfahrung – leider (noch) nicht systematisch erhoben – ist:

  • Java schneidet in puncto Speichernutzung oft richtig, richtig mies ab. Es gab in der Vergangenheit bei uns sogar Leute, die mehr als 80 GiB pro Rechnerkern (Core) veranschlagten – und das bei vielen, vielen Rechnungen**. Allerdings gibt es auch bessere Java-Programme in der Liga, die mit kompilierten Programmen mithält.
  • PyPy, der just-in-time Compiler für Python, ist auch keine Lösung. Mag sein, dass Python so sehr viel schneller gemacht wird. Aber das Risiko die Geschwindigkeit mit erheblich höheren Speicherverbrauch zu erkaufen oder / und mit nicht portierbaren Lösungen dazustehen ist groß.
  • Cython, ein Weg Pythoncode tatsächlich zu kompilieren und zu beschleunigen wird selten genutzt.
  • Python wird oft derart mies umgesetzt, dass ich mich schon gedrängt gefühlt habe Hinweise zu geben, wie es besser geht – ohne, dass wir auf unserem Hochleistungsrechnern überhaupt Python als sog. Produktionscode (also Skripte, die den Kern von Berechnungen bilden und häufig laufen) sehen wollen – sie sind nicht nur Verschwendung teurer Resourcen, es ist auch unfair, wenn das langsamste Skript anderen Nutzern Rechenzeit nimmt. Um die Bioinformatik mal zu entlasten: Bei uns sind es auch theoretische PhysikerInnen, die schöne Algebra nutzen, diese 1:1 in Python gießen — und sich dann wundern warum die Skripte sooo langsam sind.
  • Linux ist selbstverständlich nicht langsamer – das scheint mir eine Auswirkung der Compilerwahl und Einstellungen zu sein. Das Paper bleibt vage.
  • Perl kommt in neueren Projekten nur noch selten vor. Es scheint an Bedeutung verloren zu haben.
  • R fehlt in dem Vergleich völlig. Diese Sprache wird bei uns einfach so benutzt oder R-Pakete, wie Bioconductor, also eine Bibliothek, die viele Lösungen schon enthält. Bei R und insbesondere Bioconductor ist viel in C oder C++ implementiert und R dient nur als Schicht, die die AnwendungsprogrammiererInnen nutzen – mal kann man also sehr gute Performance erreichen, mal kann man Pech haben und eine naiv implementierte Bibliothek verwenden, die einen Flaschenhals mitbringt. Auch R bietet einen just-in-time Compiler, der bei uns allerdings selten genutzt wird.

Wieso ist das wichtig?

Meine Auswahl der Sprachen und Kenntnisse ist nicht willkürlich. Andere denken auch, dass diese Sprachen und zusätzlich Shellkenntnisse wichtig sind. Natürlich kann man über Details diskutieren. Und solchen Vergleichen wohnt immer der Funke zum Flamewar inne. Also, erst mal durchatmen …

Es ist schließlich egal, ob ein Problem in 2 Sekunden oder 2 Stunden gelöst wird. Ja, das ist für die meisten Probleme wirklich völlig gleichgültig. Und C oder C++ stellen die meisten BioinformatikerInnen vor große Hürden. Warum das so ist, weiß ich nicht. Aber da ist es naheliegend, zu Skriptsprachen wie Python oder R zu greifen. Zu einem echten Problem wird das erst bei richtig großen Datenmengen, wenn also eine Rechnung nicht ein paar Mal, sondern Millionen Male durchgeführt werden muss:

 

Meine “Motivationsfolie” zum Hochleistungsrechnen. Bild: gemeinfrei, Idee: Lennart Martens

Zum Problem werden interpretierte Sprachen auch, wenn Sie Lösungen verhindern, z. B. weil bereits eine “Lösung” vorliegt, die zwar langsam ist und nur proof-of-concept, also nicht mit allen Eigenschaften (features) versehen, die man braucht. Eine neue, bessere Implementierung wird selten finanziert. Und so vertrete ich die Auffassung, dass vor Start eines Programmierprojektes u. a. überlegt werden sollte:

  • Soll mein Programm einmal von Dritten genutzt werden? Nein? Dann sind viele weitere Entscheidungen “Privatsache”. Ja? Dann gilt es sorgfältiger zu überlegen. Nicht vergessen: Der Fokus hier ist wissenschaftliche Software, die veröffentlicht werden soll. Eigentlich selbstverständlich wird aber oft vergessen.
  • Wer entwickelt eigentlich? Ich im stillen Kämmerlein? Meine Kollegen mit mir? Eine große Gruppe (mich eingeschlossen) über Gebäude, Länder, vielleicht Kontinente verteilt? Das hat zumindest Einfluss auf die Erwartungshaltung, aber auch auf die Codestruktur.
  • Wer soll meine Software wie nutzen? Eine Webanwendung unterliegt anderen Kriterien als eine graphische Benutzeroberfläche, als Programme, die auf der Kommandozeile zu nutzen sind.
  • Auf welchen Datenmengen soll meine Software arbeiten? Eine kleine Tabelle oder möglicherweise Terabyte von Rohdaten?
  • Und weiter: Welche Algorithmen liegen vielleicht schon optimiert vor? Wie kann ich die mit welcher Sprache nutzen? Welche Parallelisierungsstrategien kann ich damit verfolgen?

Die Liste ließe sich lange fortsetzen. Aber vielleicht dämmert es Euch schon, warum meine Kollegen und ich die Auffassung vertreten:

  • Interpretierte Sprachen sind toll, man kann damit viel machen. Insbesondere kann man langsamen und schnellen Code schreiben. Schnellen Code zu schreiben ist ähnlich aufwendig, wie gleich schnellen, zu kompilierenden Code zu schreiben (oft auch unmöglich). Insbesondere leiden Parallelisierungsstrategien in interpretierten Sprachen an ihren engen Grenzen.***
  • Daher sollten interpretierte Sprachen für Aufgaben genutzt werden wie Schnittstellen (Wrapper) zu anderen Programmen bereitstellen, Daten graphisch aufzubereiten (zum Plotten), einen Workflow zu skripten, etc..

Persönlich bin ich kein Anhänger des “interpretierte Sprachen haben im Hochleistungsrechnen nichts zu suchen”, aber ihr habt hoffentlich heraus gelesen, dass ich für Sorgfalt in der Wahl der Mittel plädiere.

Meine Schlußfolgerung

Tatsache ist, dass sehr viel Bioinformatiksoftware auf der Grundlage von interpretierten Sprachen publiziert wird (Zwischenstand meiner Erhebung: 80-90 %). Und ist eine Lösung einmal da, wird sie auch genutzt. Auch wenn sie langsam, schwer zu installieren ist und noch andere Probleme mit sich bringt. Man kommt halt schwer zu besseren Alternativen. Und das ist ein Problem, weil langsame Lösungen, die millionenfach Verwendung finden auch viel Strom und Zeit der Anwender und Geld für zusätzliche Hardware verbrauchen – unnötig.

Ganz übel ist die Situation dennoch nicht, denn Qualität setzt sich durch. Die in der bioinformatischen Datenanalyse meist verwendeten Programme (in Bezug auf Rechenzeit) sind in C oder C++ geschrieben oder auch R (mit C oder C++ im Hintergrund). Außerdem spielt Python auch eine große Rolle im maschinellen Lernen – auch hier wieder als “Wrapper” um kompilierten Code, teils sogar für Graphikkarten.

Lösung für Interpreter gibt es häufiger – aber die damit “verschwendete Rechenzeit” hält sich in Grenzen, da diese Lösungen dennoch kurze Laufzeiten aufweisen (z. B. für einen kleinen Plot). Und wichtiger als Grundsatzdebatten ist die Möglichkeit wissenschaftliche Erkenntnisse zu gewinnen. Da spielt REPL eine Trumpfkarte: Die Entwicklung von komplexer Software in kompilierten Sprachen kostet weitaus mehr Zeit als vergleichbare Lösungen in interpretierten Sprachen. Die Überlegung “zu welchem Werkzeug greife ich?” ist eine große Herausforderung. Zumindest – und DAS zeigen solche Vergleiche, sollte man sich nicht nur von Moden leiten lassen.

Und zu guter Letzt gibt es inzwischen auch gute Bibliotheken für die Bioinformatik, die das Entwickeln in C++ oder Rust vereinfachen. Und da purzeln auch Anwendungen heraus: Ein Silberstreif am Horizont bioinformatischer Anwendungsentwicklung …

 


* Ich “kompiliere” mit dem Compiler – ja, das ist inkonsequent.

** Wir haben derartige Rechnungen/Jobs stark eingeschränkt. Auf einem Tier3-System. Nur falls jemand mit HPC-Erfahrung verwundert einwenden will, dass so Etwas bei ihr / ihm ja gar nicht gehe.

*** Ja, es gibt mpi4Py oder Rmpi (bewußt nicht verlinkt), aber das unterstreicht eher meinen Punkt: Langsame Algorithmen / Implementierungen können viel besser skalieren (wenn ich meine CPUs lange nutze, kann das Zufügen von CPUs zu einer besseren scheinbaren Nutzung führen. Aber dennoch ist das a) eine Verschwendung von Ressourcen und b) gibt es bei interpretierten Sprachen viel engere Grenzen, der Skalierbarkeit. Es gibt keinen Fall, wo man damit viele tausend CPUs gleichzeitig nutzen kann.

flattr this!

Kommentare (50)

  1. #1 Nestiiii
    Linz
    6. November 2019

    Hallo Christian – Netter Artikel – Danke dafür!

    Einen kleinen Hinweis hätt ich -> Du schreibst
    …”Sie ist immerhin schon 10 Jahre alt und listet zusätzlich C#, aber die Sprache ist mir egal, weil ich unter Linux arbeite (HPC cluster arbeiten z. Zt. ausschließlich unter Linux und zusätzliche Laufzeitumgebungen, wie mono, machen die Software nicht schneller oder leichter zu nutzen).” – Es gibt jetzt .NET Core – läuft super unter Linux, ist OpenSource und die Zukunft von .NET – die neusten C#8 Sprachfeatures sind mit .NET Core 3 verfügbar. Als IDE lässt sich VisualStudioCode unter Linux/Mac/Windows nutzen.

    Lg

    • #2 Christian Meesters
      6. November 2019

      mono war nur ein Beispiel, klar. .NET Core ist keine wirkliche Alternative: In der HPC Community fällt so ziemlich alles aus dem Redmonder Haus unter den Tisch. Der Grund ist einfach, dass man immer zusätzliche, unnötige Abhängigkeiten einhandelt und es gute freie Alternativen gibt. Vor allem aber, dass Parallelisierung über viele tausend Kerne mit .NET Core auch nicht angedacht, aber schlicht manchmal notwendig ist.

      Meine pers. Meinung: Ob Veröffentlichung wissenschaftlicher Resultate oder Programmierung – in keinem Fall sollte die öffentliche Hand Geld für Dienstleistungen ausgeben, die mit der angebotenen Lösung zusätzliche Abhängigkeiten und abermalige Investitionen erfordern. Vielleicht sollte ich mal darüber schreiben? Vielleicht mal über Matlab???

  2. #3 echt?
    6. November 2019

    Das Problem ist oft die Dokumentation der Ergebnisse. Wenn die Berechnungen nicht zu umfangreich sind, reicht da VBA in Excel völlig aus. Im Übrigen könnte die Ablehnung von “neuen” Programmiersprachen daran liegen, dass die User irgendwann keinen Bock mehr haben sich in die neuundneunzigste Programmiersprache einzuarbeiten. Kurioser Weise ist man bei VBA fast wieder beim uralten BASIC angekommen.

    Da gerade Wissenschaftler mit Zeitvertrag nicht ewig an Supersoftware fummeln können und die meiste Software nach der Promotion im Orkus verschwindet, sehe ich das Problem gelassen. Interessant wäre eine Abschätzung,

    • #4 Christian Meesters
      6. November 2019

      Da gerade Wissenschaftler mit Zeitvertrag nicht ewig an Supersoftware fummeln können und die meiste Software nach der Promotion im Orkus verschwindet, sehe ich das Problem gelassen.

      Na ja, aber das Software publiziert wird und allenfalls den “workfs-for-me”-Status erreicht ist schon problematisch: Zwar wird nur ein kleiner Prozentsatz aufgegriffen, aber die Bitte Tool X der neuesten Publikation zu installieren wird häufig an unsereins herangetragen. Wie oft mußte ich schon sagen: Jau, aber das geht nicht; die Entwickler melden sich nicht, um den Bug zu beseitigen; die Entwickler nehmen keinen Patch mehr an, etc. etc.. Insofern bin ich schuldig im Sinne der Anklage: Da fehlt mir Gelassenheit ;-).

  3. #5 echt?
    6. November 2019

    welcher Prozentsatz an “wissenschaftlicher” Software wirklich langfristig genutzt wird.

  4. #6 Karl Mistelberger
    mistelberger.net
    6. November 2019

    Bei diesem Thema kommt ein wichtiger praktischer Effekt viel zu kurz. Zwar sind kompilierte Programme bei gekonnter Optimierung schneller als interpretierte.

    Die typischen Aufgaben im Ingenieurwesen und in der Wissenschaft haben eines gemein: Die Leute benutzen in fast allen Fällen für die eigentliche Arbeit hoch optimierte Libraries, so dass die im Interpreter verbrachte Zeit zu vernachlässigen ist.

    Ein kleines Beispiel zur Veranschaulichung:

    https://www.fourmilab.ch/fbench/fbench.html

    Entscheidend ist also in den meisten praxisrelevanten Fällen nicht wie schnell eine Sprache ist, sondern ob es für sie optimierte Libraries gibt.

    • #7 Christian Meesters
      6. November 2019

      Völlig einverstanden – nur muss man halt seine Werkzeuge nach den Aufgaben auswählen. Ich schrieb glaube ich: Die Frage ist ja, soll meine Software nur eine kleine Tabelle bearbeiten oder terrabyteweise Daten?

  5. #8 H.Wied
    6. November 2019

    Bei Programmen ist auch der Kopierschutz wichtig. Damit ist jetzt der Klau der Idee gemeint, also der Quelltext.
    Eine .exe Datei zu kopieren hat wenig Sinn, weil das Progaramm damit nicht abgeändert werden kann. Der Ideenklau findet nicht statt.
    Bei Interpretern ist das anders. Da kann ein Programmierer, der den Sinn eines Programmteils versteht, diese Teile verwenden und sich damit viel Arbeit sparen.
    Ein compiliertes Programm ist einfach sicherer.

    • #9 Christian Meesters
      6. November 2019

      DA muss ich widersprechen: Wissenschaft lebt von Offenheit. Kompiliert oder nicht hat nichts mit der Frage zu tun, ob die Software quelloffen ist. Prä-kompilierte Programme installieren wir aus Performancegründen nur ungern – wenn überhaupt.

  6. #10 tomtoo
    6. November 2019

    @christian
    Wäre für die Bioinformatik eine Sprache wie Julia nicht genau das richtige? Compiliert, parallelisiert. Von Anfang an für den Wissenschaftler im Hinterkopf. Zudem leicht mit Phyton und c++ zu verbinden.

    • #11 Christian Meesters
      6. November 2019

      Wäre für die Bioinformatik eine Sprache wie Julia nicht genau das richtige?

      Klar, auch die Leute bei Julia versucht im Wettbewerb mit zu mischen. Hätte ich auch aufzählen müssen. Aber Julia ist mir seid der EuroScipy 2014 im Alltag nicht untergekommen. Der Grund ist mir nicht klar. Unser build-framework bietet nur prä-kompilierte Binaries, die offenbar kaum nachgefragt werden. Also: Warum Julia eine offenbar geringe Rolle spielt, kann ich nicht beantworten.

  7. #12 tomtoo
    6. November 2019

    Julia wäre doch evtl. eine passende Alternative?
    https://m.youtube.com/watch?v=6CpPd6tkokQ

  8. #13 Christian Meesters
    6. November 2019

    @all: Warum die Kommentare von mir freigeschaltet werden müssen, habe ich noch nicht raus. Eigentlich sollte das den Einstellungen nach nicht(!) der Fall sein. Ich werde nachfragen. Diskussionen unterbinden ist meine Sache nicht.

  9. #14 rolak
    6. November 2019

    habe ich noch nicht raus

    Wohl ein unterbliebener code review – und wenn es nur bzgl des GUI für den Blogger ist…

  10. #15 rolak
    6. November 2019

    (sorry für DoppelFreischaltArbeit, Thementeil verschlunzt)

    Der Unterschied zwischen CompilerSprache und InterpreterSprache ist doch konstruiert bzw unnötigerweise aber bewußt existent gehalten. Es ist halt ein Armutszeugnis, wenn für durchaus akzeptable InterpreterSprachen kein ordentlicher Compiler generiert wird. Klar, dann gehen einige SpezialEffekte nicht ohne (ins Kompilat einzubindende) InterpreterTeilruntime, als Beispiel nur das ziemlich verbreitete eval() und seine funktionalen Schwestern. Just diese Funktionalität wird typischerweise von denselben Dumpfbacken zwingend compilierbar eingefordert (bzw als ‘sorry’-Argument für ‘generell nicht kompilierbar’ vorgeturnt), die bei der kleinsten code-verändernden Praxis in ASM and elsewhere Zeter und Mordio schreien…

    Hab noch keinen (wg dem flotten turnaround) RAD-Nutzer sich beschweren hören, daß jedesmal so grotesk große libs eingebunden werden.

    • #16 Christian Meesters
      6. November 2019

      Es ist halt ein Armutszeugnis, wenn für durchaus akzeptable InterpreterSprachen kein ordentlicher Compiler generiert wird.

      Warum? Wie soll das im Allgemeinen funktionieren? Dynamische Sprachen können ja den Typ einer Variable ändern lassen. Zwar gibt es z. B. Cython, aber da werden im Python-Modus halt auch Pythonobjekte generiert. In C zwar und damit messbar schneller, aber immer noch viel langsamer, als wenn man die Typen definiert (wenn man sie eingrenzen kann).

  11. #17 Alexander Hoßdorf
    6. November 2019

    Hallo, als Informatiker fehlt mir bei deiner Bewertung die Betrachtung der Typsicherheit als wichtiges Qualitätskriterium zur Korrektheit der Software. Überspitzt ausgedrückt: Viele einfache Fehler findet der Entwickler bereits beim Kompilieren, während beim Interpretieren erst der Anwender der Software diese Art von Fehlern entdeckt.

    • #18 Christian Meesters
      6. November 2019

      Ja, das ist ein Aspekt, den ich unterschlagen habe. Danke.

  12. #19 LasurCyan
    6. November 2019

    Warum die Kommentare von mir freigeschaltet werden müssen, habe ich noch nicht raus.

    Teamwork Christian! Frag einfach bei Deinen Kolleg*nnen hier bei SBs nach..

    Danke für die Beiträge bisher, hier schau ich gern öfter vorbei, auch, oder gerade weil es überhaupt nicht mein Fachgebiet ist^^

    • #20 Christian Meesters
      6. November 2019

      Frag einfach bei Deinen Kolleg*nnen hier bei SBs nach..

      Das habe ich angekündigt und getan – auf Seiten von Konradin wird nach dem Fehler geschaut.

  13. #21 Spritkopf
    6. November 2019

    Was für Anwendungen werden denn überhaupt in der Bioinformatik entwickelt? Mir fehlt da ein bißchen der Überblick und daher kann ich deine Anmerkungen, welche Sprachen wieviel Hardwareleistung und Resourcen fressen, gar nicht einordnen. Wie du schon richtig schreibst: Wenn man nur ein paar Tausend Datensätze abzuarbeiten hat, dann langt dafür eine interpretierte Sprache vollauf. Bei Millionen oder noch mehr Datensätzen ist das gleich ein ganz anderer Schnack.

    Und C oder C++ stellen die meisten BioinformatikerInnen vor große Hürden.

    Das wundert mich. Ist denn die Informatik in der Disziplin Bioinformatik so stark unterrepräsentiert? (Jaja, ich weiß: C++ != Informatik).

    • #22 Christian Meesters
      6. November 2019

      Ist denn die Informatik in der Disziplin Bioinformatik so stark unterrepräsentiert?

      1. Ist das abhängig vom Studiengang und -ort.
      2. Gibt es nicht die Bioinformatik, sondern verschiedene Ebenen von der Anwendungsseite bis zu den genuinen “Ausschließlich-EntwicklerInnen”. Aber Software veröffentlichen tun alle.
      3. Und – das ist leider nicht unwichtig: Oft wird in nicht IT-affinen AGs ein/e IT-affiner Student/in darangesetzt ein spez. Problem zu lösen. Diese Lösung wird dann veröffentlicht.

      Offen einzusehen, was es so gibt ist BMC Bioinformatics – ja, da ist nicht alles so schlecht, wie ich suggeriere.

  14. #23 user unknown
    https://demystifikation.wordpress.com/
    7. November 2019

    Performance ist ein schwieriges Problembündel. Wenn man nicht tagaus/tagein programmiert, Erfahrungen sammelt, sich weiterbildet usw. verzettelt man sich leicht in Microoptimierungen.
    Vollzeitprogrammierern, die man beauftragt ein funktionierendes Programm nochmal umzusetzen, diesmal nach den Regeln der Programmierkunst, fehlt vielleicht für die Aufgabe dann das Biofachwissen. Abhängig von der Größe der Programme kann es ewig dauern, sich da einzuarbeiten.
    Wenn man sich nur die Programme vorknöpft, die häufig und/oder sehr lange laufen hat man vielleicht zu wenige Aufträge, um einen Programmierer wirtschaftlich gewinnbringend auszulasten.

    Mit Aufkommen des “just in time” Compilers in der Java-Virtual Machine (VM) wird nicht mehr “nur” interpretiert, doch andererseits gibt es kein ohne Java-VM ausführbares Programm.

    Das ist nicht klar verständlich. Der JIT-Compiler ist ja nicht erst gestern aufgekommen, sondern schon Ende der 90er. Aber von Beginn an wurden Javaprogramme compiliert — nicht zu Maschinensprache für die verschiedenen Zielplattformen, sondern zu einem Zwischencode, genannt Bytecode, obwohl ja auch Quellcode und Maschinencode in Bytes rumliegt.

    Also wann wurde Java Deiner Meinung nach nur interpretiert?

    Der JIT-Compiler hat dazu geführt, dass weniger vorher compiliert wird, weil erst zur Laufzeit die Maschine, auf der das Programm läuft, analysiert wird und daher individuelle Optimierungen möglich sind und zweitens der Programmfluss empirisch analysiert werden kann, so dass besonders häufig durchlaufene Teile aggressiver optimiert werden können.

    In Scala gibt es übrigens von Beginn an eine REPL, obwohl der Code auch zu Bytecode compiliert werden kann und Java hat sein wenigen Jahren jetzt auch eine JShell genannte REPL.

    Und von Nieschenprodukten, die Javacode in Maschinensprache umgewandelt haben, habe ich auch immer wieder gehört, mich allerdings nicht weiter dafür interessiert, weil ich es gerade interessant fand, zur Not für Windowstüten Programme unter Linux schreiben zu können. Bekannt wurde nichts davon – vielleicht haben die auch nur den Code zusammen mit einer JVM in ein Archiv gepackt, in dem die JVM versteckt war, und das Programm hat sich zur Laufzeit dann samt JVM immer entpackt und gestartet – keine Ahnung. Auf Linux gab es auch so eine merkwürdige Entwicklung mit nativ ausführbarem Javacode, der aber auch keine große Fanbasis fand – ob die irgendwie getrickst haben und was die gemacht haben, weiß ich auch nicht – normale ELF-Binaries sind da meine ich auch nicht rausgefallen – ich bin da nur oberflächlich informiert, weil das trotz einer gewissen Anfangsneugier nicht leicht zu eruieren war.

    Nun, und jenseits der PC-Welten gab es noch die Javacard, keine Intelplattform, die m.W. Javacode nativ ausgeführt hat und extra dafür entwickelt worden war, damals, bei SUN.

    Und einen 8- oder 16-Bit-Controller hatte ich namens JControl-Unit, der konnte mit einer Teilmenge der JRE-Libraries, sehr, sehr abgespeckt, arbeiten; die Syntax in der man seine Programme geschrieben hat war Java, aber wegen der Unvollständigen Standardimplementierung wohl nicht offiziell Java. Den Quellcode konnte man auch auf dem PC kompilieren und laufen lassen, aber in die umgekehrte Richtung das meiste nicht – keine Swing-GUI zum Beispiel. Aber da würde ich einräumen, dass man das nicht unbedingt Java nennen muss.

  15. #24 rolak
    7. November 2019

    Warum? Wie [compiler] (..) Typ einer Variable ändern [Cython langsam]?

    vorab) Du bist in eine andere Unterscheidung hinübergehüpft, Christian, unterscheidest nicht mehr (wie im Titel noch) zwischen verschiedenen Übersetzungs-, sondern zwischen verschiedenen SprachKonzepten. Selbsterständlich sind unterschiedliche Sprachkonzepte generell durch unterschiedlichen Aufwand bei Implementierung und Laufzeit ‘gesegnet’.

    /warum/ um möglichst viele mögliche Fehler bereits zur Übersetzungszeit abfangen zu können. Diese KundenSicherheit wird selbstverständlich, wie bereits von Alexander angemerkt, von diversen Sprachkonzepten mehr oder weniger gemindert bis torpediert. Letztere sind allerdings eine ProduzentenEntscheidung in Möglichkeitsbereichen à la dynamische Typisierung&Abarbeitung (automagisch ohne Nachdenken | benutzergeführt mit existentem Konzept) – und für ersteres gibt es ausreichend abschreckende Beispiele.

    /wie../ zuerst einmal wird nicht der Typ der Variable geändert, sondern der Typ des von ihr referenzierten(→) Objektes – und das ist Übersetzer-unabhängig zB durch Datenpaare (→TypeDef, →MemoryPicture) realisierbar, egal ob nun die Typdefinition in das Speicherbild integriert wird oder separat gelagert wird. (Bsp)

    • #25 Christian Meesters
      8. November 2019

      Du bist in eine andere Unterscheidung hinübergehüpft

      Na ja, Du bist angefangen einen Rant zu schreiben und ich habe, weil ich implizit ja nur dynamische Sprachen in dem interpretierten Töpfchen hatte, Annahmen getroffen, die ich an der Stelle wohl nicht hätte treffen sollen. Mea Culpa.

      Das Konglomerat Scala/Spark/(Hadoop/Java) habe ich ja überhaupt nicht betrachtet – es war einfach nicht im Fokus dieses Artikels.

  16. #26 Karl Mistelberger
    mistelberger.net
    7. November 2019

    Ohne ausgefeilte und effiziente Technik ist alles nichts, sei es bei der Hardware oder bei der Software:

    https://media.ccc.de/v/35c3-9703-supermuc-ng

  17. #27 Karl Mistelberger
    mistelberger.net
    7. November 2019

    > #13 Christian Meesters, 6. November 2019
    > Warum die Kommentare von mir freigeschaltet werden müssen, habe ich noch nicht raus. Eigentlich sollte das den Einstellungen nach nicht(!) der Fall sein. Ich werde nachfragen. Diskussionen unterbinden ist meine Sache nicht.

    Nicht nur auf die Hardware und die Software an sich kommt es darauf an. Da benutzen zwei Leute WordPress. Sie machen aber gänzlich unterschiedliche Erfahrungen:

    https://karlmistelberger.wordpress.com/2010/10/30/karls-hug-for-the-happiness-engineers/

  18. #28 Karl Mistelberger
    mistelberger.net
    8. November 2019

    > #23 user unknown, 7. November 2019
    > Performance ist ein schwieriges Problembündel. Wenn man nicht tagaus/tagein programmiert, Erfahrungen sammelt, sich weiterbildet usw. verzettelt man sich leicht in Microoptimierungen.

    Dass das Rumbasteln nicht viel bringt fällt ziemlich schnell auf und stellt daher kein Problem dar.

    > Vollzeitprogrammierern, die man beauftragt ein funktionierendes Programm nochmal umzusetzen, diesmal nach den Regeln der Programmierkunst, fehlt vielleicht für die Aufgabe dann das Biofachwissen. Abhängig von der Größe der Programme kann es ewig dauern, sich da einzuarbeiten.

    Um ein Programm zu optimieren braucht es kein Fachwissen. Es reicht, die verschiedenen Probleme der Benutzer zu analysieren und sich mit deren Unterstützung mit dem Ablauf der jeweiligen Berechnung vertraut zu machen. Um einen effizienten Mail Server zu schreiben braucht es kein Wissen darüber, was in den einzelnen Mails drinnen steht.

    Momentan bereiten mir Fotoalben Kopfzerbrechen, hier ein Beispiel:

    https://www.mistelberger.net/Tiger/index.html

    Alle meine Fotos sind derzeit in einem Album mit ca 60.000 Bildern und Filmchen aufgehoben. Wenn ich von einer Wanderung zurück komme lade ich die Fotos hoch, was sehr schnell erledigt ist (einige Sekunden).

    Für ein konsistentes Album müssen die zugehörigen 2.000 index.html und data1.json überprüft und gegebenenfalls aktualisiert werden. jAlbum bietet derzeit nur die Brute Force Methode: alle neu erstellen (einige Minuten) und hochladen (einige zehn Minuten).

    Ein make Algorithmus könnte die Prozedur erheblich abkürzen. Der Hersteller sieht sich aber nicht in der Lage, diesen zu implementieren.

    Preisfrage: Welche Optionen habe ich?

  19. #29 rolak
    8. November 2019

    angefangen einen Rant zu schreiben

    Nee, Christian, das war ein Kommentar mit einem kleinen RantMittelteil, gerichtet an die (vorgeblichen) Jünger* des auf ewig unveränderlichen Codes.

    nur dynamische Sprachen in dem interpretierten Töpfchen

    Nun, das war ja wohl bestenfalls eine Unterteilung nach ‘kennt man eher mit’, da in der I-Liste auch Sprachen mit Compiler, in der C-Liste auch Sprachen mit Interpreter sind (jaja, ich weiß, das scheinen viele nicht zu wissen (Bsp))

    Konglomerat Scala/Spark/(Hadoop/Java)

    Sorry? Hab ich davon?

    NeeNee, prinzipiell machen Interpreter und Compiler erst mal genau dasselbe: sie unternehmen den Versuch, den Quelltext mittels lexikalischer Analyse zu verstehen, zu überprüfen und zu übersetzen in (meta für Compiler2, bytecode für Interpreter2, incremental build, direkte Aktion, <was auch immer noch kommen mag>).
    Diese ach so tolle Wahlfreiheit bei der dynamischen LaufzeitTypisierung, ist sie überhaupt so frei? Wo kommt der neue, zur SourceGenese noch unbekannte Typ denn her? Kann es vielleicht doch sein, daß aus der lokalen codebase oder gar aus dem wildwildweb ein script nachgeladen wird, das (typischerweise für den Rest der Laufzeit) die entsprechenden Methoden und overloads für den neuen Typ bereitstellt?
    Was selbstverständlich (per Definition der jeweiligen Sekte) etwas völlig anderes zu sein hat als das LaufzeitLaden einer compilierten dynamischen Bibliothek, die (so lange wie geladen) Typ, Methoden und overloads bereitstellt.

    Klar, Compiler generieren typischerweise binblobs, doch die so hoch gelobten precompiled libs für Interpreter, die das Warten so angenehm verkürzen – das sind ebenfalls binblobs, nur vielleicht etwas niedlicher.
    Doch: Warum kein IDE mit einem Interpreter, das auf *click* ein Kompilat generiert, wenn der Zustand ‘so soll es sein’ erreicht ist? Klar, für dieses Konzept müßte auf ein wenig vom lazyweakTyping verzichtet werden (nicht auf das dynamische!), dafür gibts dann aber auch weniger Grusel bei den so häufigen unsicheren Typumwandlungen.

    • #30 Christian Meesters
      8. November 2019

      Sorry? Hab ich davon?

      Nee, sorry, da habe ich etwas aufgegriffen, dass nicht von Dir stammt.

      Zu Deiner Antwort: Ja, schon. Ich möchte, dass Du Verständnis dafür hast, dass ich stark vereinfache, weil ich immer wieder Leute vor mir habe, die ein erstes Mal ‘ls’ eingeben — und dann den Bogen über Programmierung, Debugging, Profiling bis zum Bauen von Workflows spannen muss. Du darfst mich gerne darauf hinweisen, wenn ich unzulässig vereinfache.

      Ja, Interpreter und Compiler sind sich sehr ähnlich, sie machen zunächst erst mal dasselbe. Allerdings arbeiten Compiler prinzipiell vor Start eines Programms, während Interpreter (der von mir genannten Sprachen) dynamisch auf (potentiell veränderlichen) Code reagieren müssen. Damit haben Compiler auch die Möglichkeit weitergehend zu optimieren und auch auf andere Instruktionssätze “zurückzugreifen”. (Ja, auch das ist vereinfacht und für mein Gebiet spielt das eine große, manchmal ideologisch überhöhte, Rolle.)

      … Doch: Warum kein IDE mit einem Interpreter, das auf *click* ein Kompilat generiert, wenn der Zustand ‘so soll es sein’ erreicht ist? Klar, für dieses Konzept müßte auf ein wenig vom lazyweakTyping verzichtet werden (nicht auf das dynamische!), dafür gibts dann aber auch weniger Grusel bei den so häufigen unsicheren Typumwandlungen.

      Ich verstehe worauf Du hinaus willst. Aber Du erwartest sicher von mir keine Antwort auf die Frage. Das sind schließlich Community-Entscheidungen oder / und die Einscheidungen von Sprachentwicklern.

      Es ist offenbar ein emotionales Thema. Mich würde interessieren warum. Wenn Du einen Gastartikel schreiben magst: Gerne. Ich kann andere Haltungen vertragen — und sachlich sehe ich keinen Konflikt (auch wenn ich jetzt bei all den Fragen und Betonungen nicht weiß, was ich als pers. Kritik auffassen soll).

  20. #31 Karl Mistelberger
    mistelberger.net
    9. November 2019

    > #30 Christian Meesters, 8. November 2019
    > Ja, Interpreter und Compiler sind sich sehr ähnlich, sie machen zunächst erst mal dasselbe.

    Die Java Virtual Machine ist schon einmal eine gute Idee:

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

    Damit geht alles:

    “In this post, I wanted to finally give a proper introduction to GCC-Bridge, a C/Fortran compiler targeting the Java Virtual Machine (JVM) that makes it possible for Renjin to run R packages that include “native” C and Fortran code without sacrificing platform independence.”

    https://www.renjin.org/blog/2016-01-31-introducing-gcc-bridge.html

    • #32 Christian Meesters
      9. November 2019

      Damit geht alles

      Die Frage ist aber nicht, was alles geht / möglich ist, sondern ob es praktisch in sinnvoller Zeit zu erreichen ist.

  21. #33 Dr. Webbaer
    9. November 2019

    Sehr interessant, der Schreiber dieser Zeilen glaubte bisher, dass das mit dem Kompilieren (vs. Interpretieren) von Code durch den Einsatz von Gerät, das vglw. günstig im Erwerb ist, verglichen mit dem Erwerb von Software-Entwicklern sozusagen weggehauen werden könnte, zumindest ein wenig zeitlich versetzt, wenn dann später das Gerät wieder günstiger und leistungsfähiger zu erwerben wäre.

    Der Schreiber dieser Zeilen hat die dankenswerterweise im dankenswerterweise beigebrachten WebLog-Eintag beigebrachten Visualisierungen bemerkt.

    Wenn Sie recht oder Recht haben, wäre dies wichtig.

    Wie stets beim Einsatz von sog. Software außerhalb der Bioinformatik, bspw. im Bereich der Wirtschaft, dort dann alles sozusagen weniger wichtig, weil die Bioinformatik eine Sonderrolle außerhalb gewohnter Wirtschaftlichkeit spielt?

    MFG – WB

    • #34 Christian Meesters
      9. November 2019

      …den Einsatz von Gerät, das vglw. günstig im Erwerb ist, verglichen mit dem Erwerb von Software-Entwicklern sozusagen weggehauen werden könnte,

      Das ist eine Frage des Geldes: Wenn die Probleme wirklich groß werden und man (also als Gesellschaft) wenig Geld hat, dann hilft nur die horizontale Skalierung (scaling out), also der Bau von Clustern. Mal abgesehen davon, dass wirklich große, fette Server irgendwann auch nicht fetter werden können: Irgendwann kommt der Punkt, wo man doch horizontal skalieren muss.

      Den Rest Ihrer Zeilen verstehe ich – mal wieder – nicht so gut, dass ich antworten möchte.

  22. #35 Dr. Webbaer
    9. November 2019

    PS :

    Ist es so, dass ein Interpretat (vs. Kompilat) einmal interpretiert, so im Rechnerspeicher bereit steht wie ein Kompilat – und wenn sich hier idF viele Nutzer-Anforderungen ergeben, es (die gesamte Ausführungsgeschwindigkeit meinend, die der Menge ihrer Ausführungen) (fast) egal ist, ob einmal (!) interpretiert statt nur geladen werden musste?

  23. #36 Solarius
    11. November 2019

    Es gibt doch compilierte Sprachen, die etwas leichter zu erlernen sind, als c und c++. Ich würde glatt mal behaupten, das Pascal ähnlich leicht ist, wie Python. Vielleicht sogar leichter. Und auch mit Pascal kann man Mehrprozessorsysteme programmieren:

    https://wiki.freepascal.org/Multithreaded_Application_Tutorial/de

    Das sieht jetzt allerdings wieder richtig kompliziert aus. Ich selber kann das nicht. Aber ich bin ja auch kein Programmierer. Ich glaube aber nicht, das das mit Python wirklich einfacher ist.

    Pascal/Lazarus wäre eine Programmiersprache, die ähnlich schnell ist wie c++ und dabei ähnlich leicht zu erlernen ist, wie Python.

  24. #37 Karl Mistelberger
    mistelberger.net
    12. November 2019

    > #32 Christian Meesters, 9. November 2019
    >> Damit geht alles
    > Die Frage ist aber nicht, was alles geht / möglich ist, sondern ob es praktisch in sinnvoller Zeit zu erreichen ist.

    Klar, schon Loriot hat festgestellt: Ein Leben ohne Mops ist möglich, aber sinnlos.

    Was mich zu meiner Zeit (1976-2003) immer verwundert hat: Die Berufspendler hatten angemessenes Geschick beim Lenken eine Autos. Wenn sie aber einmal beim Computer hinlangen sollten waren sie unbeholfen und ängstlich wie Fahrschüler.

    In der Welt von heute mit den potenziell unbegrenzten Möglichkeiten ist es notwendig, schnell und effizient den optimalen gangbaren Weg für ein bestimmtes Vorhaben herauszusuchen. Schaffen die das heute überhaupt?

  25. #38 Karl Mistelberger
    mistelberger.net
    13. November 2019

    > Bei Benchmarks, also dem systematischen Vergleich zwischen Programmen, Algorithmen, Implementierungen (also Umsetzungen in “Code”), usw. oder eben Programmiersprachen, verhält es sich ähnlich: Sie wecken schnell inneren Widerstand, weil schnell Gedanken aufkommen wie “die Leute haben X nicht berücksichtigt oder Y falsch gemacht”.

    Denken hilft hier nicht viel, hingucken macht immer schlauer:

    When Intel first released their (fantastic) compilers and MKL it was soon discovered that they worked for AMD processors but didn’t give very good performance (even though the core architecture was the same). Someone got the idea to spoof the processor ID (hard to do) on an AMD Opteron so that it responded as “Genuine Intel” sure enough the performance went way up!

    Long story, short, there was a lawsuit and a settlement. Nothing much changed except that Intel has to include an “Optimization notice” on their publications.

    https://www.pugetsystems.com/labs/hpc/AMD-Ryzen-3900X-vs-Intel-Xeon-2175W-Python-numpy—MKL-vs-OpenBLAS-1560/

    Nicht zu vernachlässigen: https://itsfoss.com/linux-better-than-windows/

    • #39 Christian Meesters
      13. November 2019

      Herr Mistelberger, es erschließt sich mir nicht, welche Intention / Nachricht Sie mit Ihren Posts hier verbinden – an mich oder / und andere LeserInnen.

  26. #40 Karl Mistelberger
    mistelberger.net
    13. November 2019

    > es erschließt sich mir nicht, welche Intention / Nachricht Sie mit Ihren Posts hier verbinden

    Anderswo nennen sich die Posts ‘Gedanken’. Ich schreibe was mir bei Lesen einfällt.

    Wo drückt der Schuh am meisten? Nennen Sie eine Nummer.

    • #41 Christian Meesters
      13. November 2019

      Anderswo nennen sich die Posts ‘Gedanken’. Ich schreibe was mir bei Lesen einfällt.

      Gerne, nur eine Diskussion mit Mehrwert ergibt sich erst dann, wenn andere folgen können. Wo z. B. ist der Zusammenhang zwischen Intels seltsamer Geschäftspolitik und dem inneren Widerstand, welcher die Akzeptanz von Benchmarks schmälert?

  27. #42 echt?
    14. November 2019

    Selbst das alte Fortran lebt noch.

  28. #43 Solarius
    14. November 2019

    Selbst das alte Fortran lebt noch.

    Ist es denn auch leicht zu erlernen? Darum geht es ja. Herr Meesters schreibt ja, das c und c++ die meisten Bioinformatiker vor große Hürden stellen. Wobei er nicht weiß, woran das liegt. Python ist sehr schnell zu erlernen. Da gibt es ja das “A Byte of Python”, das bestand früher mal aus einem Blatt Papier. Damit konnte man sehr schnell Python erlernen. Inzwischen ist das aber auch ein richtiges Buch geworden.

    Vielleicht ist aber auch gerade diese Leichtigkeit ein Problem. Man programmiert ohne wirklich gut programmieren gelernt zu haben. Und dann wird eben auch Python mies umgesetzt. Auch darüber beschwert sich Herr Meesters ja.

    Womöglich mangelt es einfach nur an gutem Programmierunterricht? – Auch dafür wäre Pascal (also Lazarus) ideal geeignet.

    • #44 Christian Meesters
      14. November 2019

      Das bringt es ziemlich auf den Punkt. Danke. (Ich muss wohl lernen nicht so grantlerisch rüberzukommen 😉 .) Alldieweil Pascal? Informatiker (hier spare ich mir das Innen, denn die Aussage kenne ich nur von den Jungs) behaupten ja gerne, dass “wer eine Programmiersprache und die Konzepte gut kennt, auch alle anderen gut lernen kann”. Da mag ich prinzipiell nichts einwenden. In der Praxis aber habe ich schon etliche Informatiker gesehen (in Masterarbeiten und Dissertationen), die in Sprache X ziemlich Java-idiomatisch geschrieben haben — weil Java Sprache Nr. 1 im Studium ist. Insofern habe ich meine Zweifel, ob man den Leuten mit Pascal einen Gefallen tut. Aber ich kenne das Argument nicht gut genug: Würde ich aufrichtig gerne kennenlernen.

  29. #45 Karl Mistelberger
    mistelberger.net
    15. November 2019

    > #41 Christian Meesters, 13. November 2019
    > Wo z. B. ist der Zusammenhang zwischen Intels seltsamer Geschäftspolitik und dem inneren Widerstand, welcher die Akzeptanz von Benchmarks schmälert?

    Ich wollte mit dem Hinweis nicht die Geschäftspolitik von Intel kritisieren, sondern auf verborgene Fußangeln beim Benchmarking hinweisen. Mangelnde Akzeptanz von Benchmarks habe ich ausschließlich bei Leuten gefunden, die eher dilettantischen Umgang mit dem Computer pflegen.

    Experten kontern mit einem aussagekräftigen Gegenbeispiel, das es mir erlaubt, entweder ihre Argumente zu akzeptieren oder meinerseits mit einem Beispiel zu antworten.

  30. #46 rolak
    2. Januar 2020

    eval()

    Im Zuge des Sichtens des Nochnichtgesehenen vom 36c3 fiel das assoziierende Stichwort:

    eval() ist der Olympus Mons unter den schlechten Ideen
    (10608 15:2)

    Es gäbe übrigens von hier noch einen Kommentar vom 9.11., der irgendeinem glitch zum Opfer gefallen ist. Nochmal?

    • #47 Christian Meesters
      2. Januar 2020

      eval() ist der Olympus Mons unter den schlechten Ideen

      Jau, und auch ich möchte noch 36c3 sichten …

      Es gäbe übrigens von hier noch einen Kommentar vom 9.11., der irgendeinem glitch zum Opfer gefallen ist. Nochmal?

      Du führst Buch? Ich kann keinen nicht-freigeschalteten Kommentar vom 9.11.2019 (oder Tage um diesen Zeitraum herum) im System finden. Wenn es Dir wichtig ist: einfach nochmal posten?

  31. #48 rolak
    2. Januar 2020

    führst Buch?

    Jein. Generell nein, selbstverständlich manchmal ja – geht ja schon mit bookmarks los. Bei Moderation typischerweise urlMerken/TabZurück/urlAnhängen/tabAuflassen bis zum Bescheid. Nach jenem Kommentar (ulkigerweise aus diesem thread) gab es einen >24h-DauerRauswurf vom SB()-System und daher verlängerten die textareas irgendwann ‘hängende Texte’. Rekonstruierbar aus mailVerkehr zu dem Thema – und so spät, weil erst heute auffiel, daß es zwei Dateien dieses Namens gab :•/
    Wichtig? Nein.
    –✂–remaining optional——————————✂—-

    [solange Kommentare eh freigeschaltet werden müssen, erlaube ich mir reichlich links…]

    offenbar .. emotional

    Mir ist nicht klar, aus welcher Offensichtlichkeit dieser (bzgl. meiner Kommentare) unzutreffende Schluß gezogen wurde.

    stark vereinfache

    Dagegen ist überhaupt nichts zu sagen, doch dieser Ansatz ist keine valide Begründung dafür, mißverständliche bis falsche Aussagen unterzubringen. So ist es weiterhin kein Alleinstellungsmerkmal von Interpretern, dynamische Typisierung zuzulassen (#16#24), ebenfalls keines, veränderlichen Code zuzulassen (#30#15), ebenfalls keines, aus zur Laufzeit gewonnen Daten neuen Code bzw neues Kompilat-Verhalten zu generieren (Lisp, Prolog oder eben ein im Kompilat mitgelieferter JIT-Compiler(#15)).

    Nicht, daß meinerseits irgendwelche Einwände gegen CodeVeränderung zur Laufzeit bestünden (zB werden nicht nur, aber auch von den von ScienceBlogs() gelieferten Seitenquellen ua gewisse script-Einbindungen entfernt, bevor diese ihrerseits den Code verändern können), doch insbesondere in einer lazy-easy-sorglos-Interpreter-Umgebung sind aus Daten generierte Codebestandteile neben dem so befriedigenden ‘guck, so geht das ganz elegant und einfach’ immer noch dasselbe Hochrisiko, gegen das SQL-injection wie Kindergarten wirkt.

    Allerdings arbeiten Compiler prinzipiell vor Start eines Programms..

    Sorry, mein Fehler, dies nicht nochmals deutlich gemacht zu haben, da dies selbstverständlich auch nach mehrfacher Erwähnung hier im thread hätte unklar gewesen sein können.
    knr

    Allerdings scheint mir beim letzten Thema und mittlerweile statt ‘prinzipiell vor’ die Formulierung ‘generell vor’ passender, weil imho ansonsten die JITterbug-Tänzer außen vorblieben.
    ..der erste Abschnitt hat sich ja seitdem erledigt, Fortschritt live

    • #49 Christian Meesters
      2. Januar 2020

      Mir ist nicht klar, aus welcher Offensichtlichkeit dieser (bzgl. meiner Kommentare) unzutreffende Schluß gezogen wurde.

      Lies #15 mal durch.

      kein Alleinstellungsmerkmal …

      etc.
      Ja, da hast Du recht – ich habe in dem Kontext geschrieben, den ich offenbar nicht deutlich genug herausgestellt habe: HPC & wissenschaftliche Applikationen. Ja, auch da habe ich zu stark verallgemeinert: Asche auf mein Haupt. Da ist das JITisieren eher unüblich und ich sollte #30 präzisieren zu “der von mir genannten Sprachen in HPC & wissenschaftliche Applikationen” – und auch “generell” statt “prinzipiell” 😉

  32. #50 rolak
    2. Januar 2020

    Lies mal

    Geschah vorsichtshalber schon vorm Formulieren. Jetzt weiter eingegrenzt fiele mir ein: Falls sich der Eindruck auf ‘Dumpfbacke’ bezieht: im Kontext ‘bigotte Argumentation’ ist das(also ≈undurchdacht) imho die freundliche Einordnung, alles in Richtung ‘absichtlich’ wäre negativer. Das war allerdings nicht emotional bezeichnet worden, sondern nur möglichst passend. Auch Nominierungen für den bug-of-the-month-club oder Wertung als tdWTF-Kandidat sind trotz des typischen Anlasses ‘erschreckend’ nicht unbedingt emotional.
    Oder allgemein: Farbige Sprache belegt keineswegs emotionales Texten. Kann aber zugegebenermaßen zu diesem Schluß verführen.

    ich habe

    Die Tage nach dem erfolglosen postVersuch fiel mir ein, daß das Thema durchaus interpretiert werden kann als ‘wie unterscheiden sich die interpretierenden und die complierenden Sprachen i(n meine)m toolset’ – auch wenn diverse generellere Formulierungen dagegen zu sprechen scheinen. Deswegen kam nix mehr.