Bitte LH_ und homer, wenn man keine Ahnung von Programmiersprachenentwicklung hat, einfach mal den Mund halten. Ansonsten erstmal einen eigenen Interpreter und Compiler entwickeln (und ich meine mehr als die zu oberflächliche und veraltete Einführung, die man an Unis und FHs so bekommt) und lernen, warum moderne Skriptsprachen anders als Python sind, dann darf man vielleicht mitreden. Diese Liste ist ziemlich absichtlich so gewählt. Zugegeben, es mag nicht eindeutig dort stehen dass viele Punkte Abwägungssache oder Skalen sind, die bei Python wiederum sehr schizophren abgewogen worden sind. Python ist z.B. sowohl als Interpretersprache als auch Compilersprache mies. Z.B:
Python ist ganz bewusst eine Interpretersprache, natürlich ist dies nicht getrennt.
Ich rede natürlich nicht davon, dass man Kompilation und Ausführung manuell anstößt. Jeder ernstzunehmende Interpreter - das schließt sogar Python ein - kompiliert die Sprache heute zu Bytecode, erst dieser wird ausgeführt. Das erkennt man z.B. an den pyc-Dateien. Wenn dem nicht so wäre, erlauben immerhin gescheite naive Interpreter und deren APIs eine reine Evaluation ohne die anschließende Exekution, z.B. um semantische Fehler anzuzeigen. Pythons Interpreter und seine C-API (Hier darf man nicht den Fehler machen, bei Python Implementierung und Sprache auseinander halten zu wollen, denn das ist bei Python nicht möglich und unter anderem ein Grund, warum PyPy keine gigantischen Verbesserungen raushauen kann. Und CPython ist keine naive Implementierung, viele Idiotien des Sprachdesigns werden dort ziemlich clever und verzweifelt kompensiert.) erlaubt dies als einer der wenigen Interpreter nicht. Das Problem, was sich daraus ergibt ist, dass alles per Statement zur Laufzeit passiert. Das schließt Dinge ein wie - Definition von Datentypen, deren Methoden, deren Metaclassen, deren Operatoren - Prüfung, ob eine Variable tatsächlich initialisiert worden ist - das reguläre Einbinden von Modulen und das alles aus mehreren Threads heraus. Sogar PHP hat das in ein paar Teilen besser gemacht. PHP! Mit der oben genannten Teilung könnte man immer noch die Dinge tun die du fälschlicherweise mit einem Compiler für unmöglich hältst. Nur z.B. mit tatsächlicher Wartbarkeit und Robustheit, oder zumindest etwas, das näher dran ist sowie als Bonus die Möglichkeit schneller Startzeiten, besserer JIT-Compilertauglichkeit, besserer Einbettbarkeit usw. Und man sollte natürlich den nächsten Schritt tun und jegliches Monkeypatching gleich im Keim ersticken. Es gibt nie einen guten Grund dazu. Es gibt viele sinnvolle Gründe und Wege, Software zu Testen. "Unit Tests", wie sie z.B. bei Python, Ruby und Perl der Fall sind gehören nicht dazu. Sobald eine Sprache zu dynamisch ist (oder sich mit Speicher vollsaugt, Mangels Tracing Garbage Collection) taugt sie im Grunde nur noch als Bashersatz und dazu gehört nunmal eine vernünftige Startzeit.
speziell beim Thema Services herrschen ganz andere Situationen heute
Grumpy (der von-Python-zu-Golang-wegmigrier-Compiler) sollte eigentlich Aussage genug sein. Und das Wichtigste ist natürlich: Mein Hund könnte Haufen kacken die bessere Web- und Serviceinfrastruktur wären, als was viele Firmen heute so führen.
aber auch sehr stark im Thema Datenverarbeitung sowie im KI-Umfeld
Das kommt aus dem akademischen Umfeld, die wissen es halt nicht besser. Akademische Softwareentwicklung ist nochmal eine Lachnummer für sich. Im Grunde brauchen diese Leute einen besseren Taschenrechner und das ist eine der wenigen Dinge die Python in Kombination mit Jupyter überzeugend schafft. Und sobald man ins professionellere Umfeld geht, rückt man wieder davon ab. Bei TensorFlow z.B. baut man nur den Syntaxbaum zusammen, weil alles anderen von Python aus zu schäbig wäre.
danke für die ausführliche Kommentierung. Python findest Du "mies". Ok. Ich habe aber noch nicht verstanden, was denn jetzt die Alternative sein soll. Wie sollen denn deiner Meinung nach typische wissenschaftlich-ingenieurmäßige Aufgabe gelöst werden: - Datenplotten: interaktive publikationsfähige Plot-Erstellung mit Funktionen wie Lasso-Selection, semi-log, contour-plots, subplots, shared axis, ... (-> matplotlib) - curve-fitting (-> numpy, scipy) - matrix-support (-> pandas) - hdf5-Support (-> h5py) - model fitting, neuronale Netze (-> scikit-learn, Tensorflow) - Schnittstellen zu numerische-wissenschaftlichen Softwarepaketen wie Abaqus, Ansys, Labview, ... Mit Python also kein Problem.
PHP oder Java helfen da ja wohl nicht weiter. Sicherlich wird es für jede dieser Aufgaben eine tolle Spezialsoftware zu kaufen geben (vermutlich nur für Windows). In der Forschung stehen dafür aber i.d.R. keine Mittel zur Verfügung. Und schon gar nicht für die Anstellung eines Programmierers.
Wenn alles gut läuft (ziemlich optimistisch, da sich seit den 60ern meist das Schlechteste durchsetzt), erledigt sich das Problem größtenteils von selbst und die Leute die "technical computing", "literal computing" usw. machen werden mit Julia ins Licht gezerrt werden. Neuronale Netze gehen fast mit allen Plattformen, z.B. auch TensorFlow. Und was die Gelder angeht: Die sind wohl da, nur nicht sonderlich gut priorisiert. Man muss sich nur mal anschauen wie spendabel diverse Institute bei diversen Softwarelizenzen sind.
Man muss sich nur mal anschauen wie spendabel diverse Institute bei diversen Softwarelizenzen sind
Ja. Das ist in der Tat ein grundsätzliches Problem. Die mit öffentlichen Mitteln geförderten Forschungsergebnisse werden oft nur mit proprietäre Software generiert und sind auch oft nur mit dieser nutzbar. Die Benutzung offener Standards in der Forschung aber auch in Verwaltung und Lehre sollte zwingend vorgeschrieben werden. Aus Erfahrung kann ich aber berichten, dass es bei den Rechenzentren und den Verantwortlichen der Universitäten große Widerstände gibt. Man will die Verantwortlichkeiten für Wartung und Pflege lieber extern auslagern (Bsp.: Bei uns wird trotz massiver Proteste derzeit das Mail- und PIM-System von Linux zu MS-Exchange migriert).
Mit der "Julia-Language" hatte ich noch nie zu tun. Das Motto klingt aber gut: "Walks like Python. Runs like C."
Soviel bla um nichts. Wir verwenden hier das .Net framework und uns steht es frei, welche Programmiersprache wir verwenden. Ich verwende Python (IronPython) und kann auf die Klassen und Methoden meiner Kollegen welche C# und VB.NET verwenden, zugreifen. Für MSIL ist die Sprache irrelevant. Rennt alles mit der gleichen Geschwindigkeit. Für Python gibt es alternative Interpreter und Compiler. Ja es werden nicht alle Aspekte der Objektorientierung abgedeckt, jedoch die meisten (Selbst exotische Dinge wie Multivererbung.)
In der Liste der beliebtesten Programmiersprachen ist python ziemlich weit oben, und das hat auch seinen Grund.
Bitte LH_ und homer, wenn man keine Ahnung von Programmiersprachenentwicklung hat, einfach mal den Mund halten. Ansonsten erstmal einen eigenen Interpreter und Compiler entwickeln (und ich meine mehr als die zu oberflächliche und veraltete Einführung, die man an Unis und FHs so bekommt) und lernen, warum moderne Skriptsprachen anders als Python sind, dann darf man vielleicht mitreden. Diese Liste ist ziemlich absichtlich so gewählt. Zugegeben, es mag nicht eindeutig dort stehen dass viele Punkte Abwägungssache oder Skalen sind, die bei Python wiederum sehr schizophren abgewogen worden sind. Python ist z.B. sowohl als Interpretersprache als auch Compilersprache mies.
Ich rede natürlich nicht davon, dass man Kompilation und Ausführung manuell anstößt. Jeder ernstzunehmende Interpreter - das schließt sogar Python ein - kompiliert die Sprache heute zu Bytecode, erst dieser wird ausgeführt. Das erkennt man z.B. an den pyc-Dateien. Wenn dem nicht so wäre, erlauben immerhin gescheite naive Interpreter und deren APIs eine reine Evaluation ohne die anschließende Exekution, z.B. um semantische Fehler anzuzeigen. Pythons Interpreter und seine C-API (Hier darf man nicht den Fehler machen, bei Python Implementierung und Sprache auseinander halten zu wollen, denn das ist bei Python nicht möglich und unter anderem ein Grund, warum PyPy keine gigantischen Verbesserungen raushauen kann. Und CPython ist keine naive Implementierung, viele Idiotien des Sprachdesigns werden dort ziemlich clever und verzweifelt kompensiert.) erlaubt dies als einer der wenigen Interpreter nicht.Z.B:
Das Problem, was sich daraus ergibt ist, dass alles per Statement zur Laufzeit passiert. Das schließt Dinge ein wie
- Definition von Datentypen, deren Methoden, deren Metaclassen, deren Operatoren
- Prüfung, ob eine Variable tatsächlich initialisiert worden ist
- das reguläre Einbinden von Modulen
und das alles aus mehreren Threads heraus.
Sogar PHP hat das in ein paar Teilen besser gemacht. PHP!
Mit der oben genannten Teilung könnte man immer noch die Dinge tun die du fälschlicherweise mit einem Compiler für unmöglich hältst. Nur z.B. mit tatsächlicher Wartbarkeit und Robustheit, oder zumindest etwas, das näher dran ist sowie als Bonus die Möglichkeit schneller Startzeiten, besserer JIT-Compilertauglichkeit, besserer Einbettbarkeit usw. Und man sollte natürlich den nächsten Schritt tun und jegliches Monkeypatching gleich im Keim ersticken. Es gibt nie einen guten Grund dazu. Es gibt viele sinnvolle Gründe und Wege, Software zu Testen. "Unit Tests", wie sie z.B. bei Python, Ruby und Perl der Fall sind gehören nicht dazu. Sobald eine Sprache zu dynamisch ist (oder sich mit Speicher vollsaugt, Mangels Tracing Garbage Collection) taugt sie im Grunde nur noch als Bashersatz und dazu gehört nunmal eine vernünftige Startzeit.Grumpy (der von-Python-zu-Golang-wegmigrier-Compiler) sollte eigentlich Aussage genug sein. Und das Wichtigste ist natürlich: Mein Hund könnte Haufen kacken die bessere Web- und Serviceinfrastruktur wären, als was viele Firmen heute so führen.Das kommt aus dem akademischen Umfeld, die wissen es halt nicht besser. Akademische Softwareentwicklung ist nochmal eine Lachnummer für sich. Im Grunde brauchen diese Leute einen besseren Taschenrechner und das ist eine der wenigen Dinge die Python in Kombination mit Jupyter überzeugend schafft. Und sobald man ins professionellere Umfeld geht, rückt man wieder davon ab. Bei TensorFlow z.B. baut man nur den Syntaxbaum zusammen, weil alles anderen von Python aus zu schäbig wäre.
danke für die ausführliche Kommentierung. Python findest Du "mies". Ok. Ich habe aber noch nicht verstanden, was denn jetzt die Alternative sein soll. Wie sollen denn deiner Meinung nach typische wissenschaftlich-ingenieurmäßige Aufgabe gelöst werden:
- Datenplotten: interaktive publikationsfähige Plot-Erstellung mit Funktionen wie Lasso-Selection, semi-log, contour-plots, subplots, shared axis, ... (-> matplotlib)
- curve-fitting (-> numpy, scipy)
- matrix-support (-> pandas)
- hdf5-Support (-> h5py)
- model fitting, neuronale Netze (-> scikit-learn, Tensorflow)
- Schnittstellen zu numerische-wissenschaftlichen Softwarepaketen wie Abaqus, Ansys, Labview, ...
Mit Python also kein Problem.
PHP oder Java helfen da ja wohl nicht weiter. Sicherlich wird es für jede dieser Aufgaben eine tolle Spezialsoftware zu kaufen geben (vermutlich nur für Windows). In der Forschung stehen dafür aber i.d.R. keine Mittel zur Verfügung. Und schon gar nicht für die Anstellung eines Programmierers.
Wenn alles gut läuft (ziemlich optimistisch, da sich seit den 60ern meist das Schlechteste durchsetzt), erledigt sich das Problem größtenteils von selbst und die Leute die "technical computing", "literal computing" usw. machen werden mit Julia ins Licht gezerrt werden.
Neuronale Netze gehen fast mit allen Plattformen, z.B. auch TensorFlow.
Und was die Gelder angeht: Die sind wohl da, nur nicht sonderlich gut priorisiert. Man muss sich nur mal anschauen wie spendabel diverse Institute bei diversen Softwarelizenzen sind.
Mit der "Julia-Language" hatte ich noch nie zu tun. Das Motto klingt aber gut: "Walks like Python. Runs like C."
Soviel bla um nichts. Wir verwenden hier das .Net framework und uns steht es frei, welche Programmiersprache wir verwenden. Ich verwende Python (IronPython) und kann auf die Klassen und Methoden meiner Kollegen welche C# und VB.NET verwenden, zugreifen. Für MSIL ist die Sprache irrelevant. Rennt alles mit der gleichen Geschwindigkeit. Für Python gibt es alternative Interpreter und Compiler. Ja es werden nicht alle Aspekte der Objektorientierung abgedeckt, jedoch die meisten (Selbst exotische Dinge wie Multivererbung.)
In der Liste der beliebtesten Programmiersprachen ist python ziemlich weit oben, und das hat auch seinen Grund.