Python Vorteile: - Während des Programmierens nebenher eine Python Shell laufen haben und einzelne Codezeilen mal schnell ausprobieren - Zwingt zum Schönschreiben von Code - Sehr gut lesbar - Man braucht nicht über Speichermanagement nachdenken.
C++ Vorteile: - Kompiliert, daher wird eine strikte Trennung zwischen Daten und Programm erzwungen. - Wenn ich "int" sage, dann ist das ein int und wird sicher nicht so nebenbei einfach zum float. - Schnellerer Code (i.a. 2-10 mal schneller). - Zwingt zum Nachdenken über Speichermanagement (was einen manchmal in den Performance-Hintern beisst).
Ich mag beide Sprachen, jede halt für den richtigen Einsatzzweck.
Deinen ersten Punkt verstehe ich nicht! Python Quellcode wird auch kompiliert - das ist also kein Unterschied. Und was meinst Du mit Trennung zwischen "Daten und Programm"? Meta-Programmierung? Oder etwas anderes? Und was ist daran "besser" oder wieso ist das "besser"?
Python ist ebenfalls stark typisiert; je nach Auffassung sogar stärker als C++. Der Unterschied ist das *dynamische*! In Python wird aus einem Integer-Objekt niemals ein Float-Objekt - in C++ gibt es sogar void-Pointer... Aber die Namen sind in Python halt nicht typisiert, sondern die Objekte, an die sie gebunden werden - das ist einfach der Unterschied.
"Schnellerer Code" ist auch unpräzise (und sogar missverständlich!). Code an sich ist niemals schnell oder langsam - es kommt darauf an, wie effizient das lauffähige Resultat ist, das man aus dem Code erzeugt / erzeugen kann. Dies ist in vielen Bereichen aber weniger wichtig, als wie *schnell man etwas in Code ausdrücken*, sprich implementieren kann! (Das war nun die Doppeldeutigkeit Deines Statements ;-)) Und da ist Python aufgrund der mächtigeren Ausdrucksstärke C++ in nahezu allen Bereichen überlegen.
Als letztes bleibt die Wahl der richtigen Algorithmen und der dazugehörigen Datenstrukturen. Erst in C++11 gibt es in der STL assoziative Container mit O(1) Zugriff! Bei großen Datenmengen spackt eine std::map gegenüber einem Python-Dictionary garantiert ab. Meiner Erfahrung nach machen die meisten Programmierer an dieser Stelle die grundlegenden Fehler! Da ist die Wahl der Sprache fast schon egal.
Ich persönlich liebe Python und finde auch gut, dass Unis sich stärker auf etwas konzentrieren, was *nicht* so stark in der Wirtschaft verwurzelt ist. Ein guter Softwareentwickler sollte lernen, welche Paradigmen es gibt und möglichst unterschiedliche Ansätze und Philosophien kennen lernen. Zudem sollte man Anfänger nicht mit einer IDE, Compilern, umständlicher Trennung zwischen Header- und Implementierungsdateien, miserablen String-Verarbeitungsmöglichkeiten usw. verschrecken. Wer wirklich das Programmieren neu lernen will oder muss, der braucht einfach eine REPL! Früher in Zeiten der guten alten Home-Computer hatte jeder eine REPL mit eingebaut, wie z.B. oftmals ein BASIC als Mischung aus heutiger Shell und REPL in einem. Insofern kommen da einfach Sprachen wie C oder C++ nicht in Frage, ja auch Java bietet da afaik noch nicht so viel - C# in Ansätzen. Dennoch haben andere Sprachen wie Scala, Ruby, JavaScript oder eben Python viel weniger Boilerplate-Code, was das Erlernen grundlegender Dinge wie Schleifen, Funktionen, Kontrollanweisungen usw. zu leicht zugänglich macht.
Mir wäre dazu noch eine rein funktionale Sprache lieb, wie etwa Clojure als praktisch einsetzbares LISP. Funktionale Programmierung ist zwar in Python auch möglich, aber eben auch vermeidbar, wenn man das funktionale nicht mag oder es sich einem nicht erschließt. Und wer mag schon funktionale Programmierung am Anfang? Der Sinn und die Freude daran erschließen sich den meisten erst später...
Wichtig sind aber eben Dinge wie Paradigmen, wie man lernt, idiomatisch guten Code zu schreiben, dass man das in einer Sprache Gelernte nicht auf alles als absoluten Wert übertragen kann (Java == OOP z.B. ) usw.
Dazu noch Methodiken wie TDD, Agile Methoden statt Wasserfallmodellen (*kotz*!), OO-Prinzipien, Design-Pattern - auch im Hinblick auf deren Trivialität in vielen Sprachen bzw. als Ausdruck einer schwachen Ausdrucksstärke in vielen Sprachen.
Last but not least, dass man ständig über den eigenen Tellerrand hinaus blicken muss, um nicht stehen zu bleiben.
Wenn ich Bewerber interviewe erlebe ich leider viel zu oft, dass die denken, alles über das Programmieren zu wissen, weil sie schon so viel Java, C++ oder auch PHP-Code geschrieben haben... fragt man nach Paradigmen, Konzepten wie O-Klassen bzw. Zeitkomplexität usw. herrscht dann zumeist Funkstille.
Früher war PC == Windows und seit einigen Jahren Programmierung == Java oder PHP. Beides ist ein Ausdruck für ein beschränktes Weltbild... und eine Uni sollte eigentlich das Gegenteil fördern! Daher empfinde ich die Zuwendung auf eine Sprache, die den Einstieg leichter gestaltet, auch wenn sie in der Industrie keine so gewichtige Rolle spielt als positiven Schritt! Mögen deutsche Unis auch mehr an die Bildung denken als an die Ausbildung!
"Python Quellcode wird auch kompiliert - das ist also kein Unterschied. "
Das ist so nicht korrekt. Per default ist Python eine Interpretersprache. Es gibt zwar einen Zwischencode, doch dies ist kein Maschinencode, sondern nur ein Struktur, welche es dem Interpreter erleichtert damit umzugehen.
Bezüglich der Typisierung weichst du stark vom allgemein gelehrten zu diesem Thema ab. Siehe statische typisierung vs. dynamische typisierung (+ diverse Zwischenmöglichkeiten). In diesem wichtigen Punkt unterschieden sich die Sprachen, und das kann man auch nicht weg argumentieren (warum sollte man auch?). In Python kann nun einmal eine Variable, die hier die Referenz zur Information an sich ist, nun einmal direkt nacheinander Werte verschiedenen Types haben. Dies ist so in strikt-typisierten Sprachen nicht möglich. Deklariert man in einer solchen Sprache eine Variable als int, so bleibt sie dies auch. In Python muss der Codeablauf dies sicherstellen, was natürlich Risiken mit sich bringt.
Bezüglich "Dies ist in vielen Bereichen aber weniger wichtig, als wie *schnell man etwas in Code ausdrücken*, sprich implementieren kann" kann ich dir ebenfalls nicht zustimmen. Üblicherweise wird Software 1x geschrieben (+ gewartet & erweitert), aber sehr oft ausgeführt. Geringe Vorteile bei der Entwicklung werden gerade in der Wirtschaft gerne von Nachteilen in der Ausführung aufgefressen. Was nützt es, wenn man 5 Stunden beim Entwickler spart, dafür dann aber tausende Anwender täglich unnötig mit langsamer Software warten lässt? In der Wirtschaft ist Ausführungsgeschwindigkeit oft sehr wichtig, ist doch die Ausführung der Software der Grund, warum sie überhaupt geschrieben wurde. Schnelle Software (je nachdem, was sie ist) nutzt die Zeit der Benutzer besser (bei eCommerce Seiten kannd as Umsatz bringen!) oder braucht weniger Server.
Ich mag Python, und nutze es fast exklusiv. Aber man sollte die Kirche im Dorf lassen.
Eine Ergänzung noch zum Thema Ausführung vs. Umsetzung: Mehr als einmal musste ich beobachten, wie jemand, der sorglos mit der Ausführungszeit einer Anwendung umging, später weit mehr Zeit in die Optimierung stecken musste, als er je bei der Entwicklung eingespart hat. Leider werden solche Faktoren oftmals ignoriert, nacharbeiten gelten dann nicht mehr als Teil des Projektes.
Da kommen schnell völlig falsche Zahlen zur Entwicklungszeit bei heraus.
In eigentlich allen Punkten, die Du beschreibst muss ich Dir leider widersprechen - und auch viele der gängigen Meinungen tun das!
Das ist so nicht korrekt. Per default ist Python eine Interpretersprache. Es gibt zwar einen Zwischencode, doch dies ist kein Maschinencode, sondern nur ein Struktur, welche es dem Interpreter erleichtert damit umzugehen.
Und worin liegt hier der Widerspruch zu meiner Antwort auf die Aussage des OP? Dieser schrieb etwas von "kompilieren" - das wird Python auch. Punkt.
Die Unterscheidung, die Du hier anstellst und *neu* in den Raum wirfst, ist an sich *künstlich*! Zeige mir mal eine gute und anerkannte Definition, was eine "Interpretersprache" ist! (Das verhält sich analog zum hässlichen Wort "Scriptsprache" ) Inwiefern unterscheidet sich ein Interpreter (virtuelle Maschine) von einem Prozessor? Welchen Unterschied macht das für die Praxis bzw. den Entwickler wirklich?
Der OP warf nur "kompiliert" in den Raum - das kann man sicherlich nicht einfach so stehen lassen, oder?
Bezüglich der Typisierung weichst du stark vom allgemein gelehrten zu diesem Thema ab.
Nein, eben nicht! Der OP verwechselte oder ignorierte das - lies das bitte noch einmal genau nach. Python ist *stark typisiert*. Punkt. Ein Objekt vom Typ A ist ein Objekt vom Typ A und bleibt es auch. Der Unterschied besteht im Aspekt der dynamischen bzw. statischen Typisierung. Genau das habe ich auch gesagt!
Üblicherweise wird Software 1x geschrieben...
Oha... bei welcher Firma arbeitest Du? Da muss ich auch hin
... (+ gewartet & erweitert)
Aha! Und da ist es wichtig, dass man den Code versteht. Bei ausdrucksstärkeren Sprachen kann das leichter fallen. Und reine Geschwindigkeit bei der Ausführung ist in den meisten Fällen entweder vernachlässigbar, oder kann durch Infrastruktur kompensiert (oft günstiger als Entwickler!) werden und wird vor allem durch gutes Design und die Wahl der richtigen Algorithmen und Datenstrukturen bestimmt! Punkt. "Premature optimization is the root of all evil!"
Natürlich gibt es Bereiche, bei denen man dermaßen optimieren muss, dass der reine Speed zählt und man Python (oder eine andere Sprache) nicht nutzen kann und für den Spezialfall auf anderes zurückgreifen muss. Aber das sind doch wirklich nicht die Regelfälle! (Und wir reden hier ja eigentlich auch von Kursen an der Uni!)
Vor allem muss man dazu vorher analysieren und messen, woran es denn hakt. Die stumpfe Meinung "C++ == schnellere Ausführung" ist pauschal einfach nicht wahr!
Non-Blocking Webserver werfe ich mal so als Stichwort - da nutzt die Sprache nix, sondern das Konzept dahinter bringt den Speed!
Im übrigen mag ich Python, ja, aber auch andere Sprachen.
C++ mag ich an sich nicht - aber spielte bei meiner Antwort keine Rolle! Es ging mir im ersten Teil darum, die falschen Aussagen des OP zu berichtigen.
Man muss Python nicht mögen, (es ist mir nicht verständlich, wie so sich die meisten Skriptsprachenentwickler nicht auf Implementationen wie mruby oder lua beschränken und für alles Standalone-mäßige schnelle Compiler entwickeln, ach ja, Faulheit), aber das beschränkt den Begriff kompilieren noch lange nicht auf Binärcode.
C++ Vorteile: - Kompiliert, daher wird eine strikte Trennung zwischen Daten und Programm erzwungen.
Nicht auf einem Von-Neumann-Rechner.
- Wenn ich "int" sage, dann ist das ein int und wird sicher nicht so nebenbei einfach zum float.
Wenn du int sagst, dann ist es entweder ein int16 oder ein int32. Zusätzlich hast du auch bei C++ einen impliziten Cast bei Verwendung von floats als Operand.
Bei Microcontroller hab ich bis jetzt nur Havard gesehen, reinrassig. Aber keiner verbietet es darauf aufbauend eine VM zu nutzen, dann gibts wieder Stanford.
Laut Wikipediaartikel sind auch manche PIC und andere MCs mit speziellen Befehlen fürs Laden und Speichern von Daten als Code ausgerüstet. Vermutlich ist heutzutage alles, was nicht auf ner Kartoffel läuft so.
Noch eine Ergänzung: Der Kontext entscheidet viele Dinge bei Python, weshalb die Shell nur für Leute ist, die die Sprache nicht beherrschen. Python zwingt dich keineswegs zum schönschreiben, nur Einrückungen sollten konsistent sein. Lesbar ist Python nur dann, wenn man sich an die Regeln guter Programmierung hält, das fängt bei PEP8 an. Natürlich muss man sich nicht um Speicherallokation kümmern, sollte trotzdem aber explizit sich Gedanken über den Verbrauch und Implementierung machen.
C++ hat gar keine Trennung. Wäre das der Fall gäbe es auch kein Recompiling. Da Python Objekte an Namen bindet ist das schon mal nicht vergleichbar und zudem wenn Operanden gleichen Typs sind kommt doch auch der Typ raus. Das Verhalten ist da identisch mit C++. Wenn man CPython mit C++ vergleicht mag das stimmen, für den Rest ist das natürlich Blödsinn. Selbst wenn alles nichts bringt, liese sich auch C++ Code integrieren.
Ergo, schwer zu glauben, dass du wirklich beide Sprachen gut genug kennst, um so einen Vergleich aufzumachen.
"weshalb die Shell nur für Leute ist, die die Sprache nicht beherrschen."
Dem kann ich so nicht zustimmen. Persönlich nutze ich die Python Shell sehr häufig, gerade weil sie vieles leichter macht. So ist die Shell in Django-Projekten (dort bereits mit der Django Umgebung über die Manage.py vorbereitet) extrem nützlich, um die Datenbank über die Klassen der Projekte anzusprechen. Das kann sowohl das debuggen erleichtern, als auch im Alltag den Umgang mit den Daten. Die Shell ist keine reine Spielweise, in einer größeren Umgebung ist sie ein nützlicher Anknüpfung zur Laufzeitumgebung.
Python Vorteile:
- Während des Programmierens nebenher eine Python Shell laufen haben und einzelne Codezeilen mal schnell ausprobieren
- Zwingt zum Schönschreiben von Code
- Sehr gut lesbar
- Man braucht nicht über Speichermanagement nachdenken.
C++ Vorteile:
- Kompiliert, daher wird eine strikte Trennung zwischen Daten und Programm erzwungen.
- Wenn ich "int" sage, dann ist das ein int und wird sicher nicht so nebenbei einfach zum float.
- Schnellerer Code (i.a. 2-10 mal schneller).
- Zwingt zum Nachdenken über Speichermanagement (was einen manchmal in den Performance-Hintern beisst).
Ich mag beide Sprachen, jede halt für den richtigen Einsatzzweck.
Deinen ersten Punkt verstehe ich nicht! Python Quellcode wird auch kompiliert - das ist also kein Unterschied. Und was meinst Du mit Trennung zwischen "Daten und Programm"? Meta-Programmierung? Oder etwas anderes? Und was ist daran "besser" oder wieso ist das "besser"?
Python ist ebenfalls stark typisiert; je nach Auffassung sogar stärker als C++. Der Unterschied ist das *dynamische*! In Python wird aus einem Integer-Objekt niemals ein Float-Objekt - in C++ gibt es sogar void-Pointer... Aber die Namen sind in Python halt nicht typisiert, sondern die Objekte, an die sie gebunden werden - das ist einfach der Unterschied.
"Schnellerer Code" ist auch unpräzise (und sogar missverständlich!). Code an sich ist niemals schnell oder langsam - es kommt darauf an, wie effizient das lauffähige Resultat ist, das man aus dem Code erzeugt / erzeugen kann. Dies ist in vielen Bereichen aber weniger wichtig, als wie *schnell man etwas in Code ausdrücken*, sprich implementieren kann! (Das war nun die Doppeldeutigkeit Deines Statements ;-)) Und da ist Python aufgrund der mächtigeren Ausdrucksstärke C++ in nahezu allen Bereichen überlegen.
Als letztes bleibt die Wahl der richtigen Algorithmen und der dazugehörigen Datenstrukturen. Erst in C++11 gibt es in der STL assoziative Container mit O(1) Zugriff! Bei großen Datenmengen spackt eine std::map gegenüber einem Python-Dictionary garantiert ab. Meiner Erfahrung nach machen die meisten Programmierer an dieser Stelle die grundlegenden Fehler! Da ist die Wahl der Sprache fast schon egal.
Ich persönlich liebe Python und finde auch gut, dass Unis sich stärker auf etwas konzentrieren, was *nicht* so stark in der Wirtschaft verwurzelt ist. Ein guter Softwareentwickler sollte lernen, welche Paradigmen es gibt und möglichst unterschiedliche Ansätze und Philosophien kennen lernen. Zudem sollte man Anfänger nicht mit einer IDE, Compilern, umständlicher Trennung zwischen Header- und Implementierungsdateien, miserablen String-Verarbeitungsmöglichkeiten usw. verschrecken. Wer wirklich das Programmieren neu lernen will oder muss, der braucht einfach eine REPL! Früher in Zeiten der guten alten Home-Computer hatte jeder eine REPL mit eingebaut, wie z.B. oftmals ein BASIC als Mischung aus heutiger Shell und REPL in einem. Insofern kommen da einfach Sprachen wie C oder C++ nicht in Frage, ja auch Java bietet da afaik noch nicht so viel - C# in Ansätzen. Dennoch haben andere Sprachen wie Scala, Ruby, JavaScript oder eben Python viel weniger Boilerplate-Code, was das Erlernen grundlegender Dinge wie Schleifen, Funktionen, Kontrollanweisungen usw. zu leicht zugänglich macht.
Mir wäre dazu noch eine rein funktionale Sprache lieb, wie etwa Clojure als praktisch einsetzbares LISP. Funktionale Programmierung ist zwar in Python auch möglich, aber eben auch vermeidbar, wenn man das funktionale nicht mag oder es sich einem nicht erschließt. Und wer mag schon funktionale Programmierung am Anfang?
Der Sinn und die Freude daran erschließen sich den meisten erst später...
Wichtig sind aber eben Dinge wie Paradigmen, wie man lernt, idiomatisch guten Code zu schreiben, dass man das in einer Sprache Gelernte nicht auf alles als absoluten Wert übertragen kann (Java == OOP z.B.
) usw.
Dazu noch Methodiken wie TDD, Agile Methoden statt Wasserfallmodellen (*kotz*!), OO-Prinzipien, Design-Pattern - auch im Hinblick auf deren Trivialität in vielen Sprachen bzw. als Ausdruck einer schwachen Ausdrucksstärke in vielen Sprachen.
Last but not least, dass man ständig über den eigenen Tellerrand hinaus blicken muss, um nicht stehen zu bleiben.
Wenn ich Bewerber interviewe erlebe ich leider viel zu oft, dass die denken, alles über das Programmieren zu wissen, weil sie schon so viel Java, C++ oder auch PHP-Code geschrieben haben... fragt man nach Paradigmen, Konzepten wie O-Klassen bzw. Zeitkomplexität usw. herrscht dann zumeist Funkstille.
Früher war PC == Windows und seit einigen Jahren Programmierung == Java oder PHP. Beides ist ein Ausdruck für ein beschränktes Weltbild... und eine Uni sollte eigentlich das Gegenteil fördern! Daher empfinde ich die Zuwendung auf eine Sprache, die den Einstieg leichter gestaltet, auch wenn sie in der Industrie keine so gewichtige Rolle spielt als positiven Schritt! Mögen deutsche Unis auch mehr an die Bildung denken als an die Ausbildung!
"Python Quellcode wird auch kompiliert - das ist also kein Unterschied. "
Das ist so nicht korrekt. Per default ist Python eine Interpretersprache. Es gibt zwar einen Zwischencode, doch dies ist kein Maschinencode, sondern nur ein Struktur, welche es dem Interpreter erleichtert damit umzugehen.
Bezüglich der Typisierung weichst du stark vom allgemein gelehrten zu diesem Thema ab. Siehe statische typisierung vs. dynamische typisierung (+ diverse Zwischenmöglichkeiten). In diesem wichtigen Punkt unterschieden sich die Sprachen, und das kann man auch nicht weg argumentieren (warum sollte man auch?).
In Python kann nun einmal eine Variable, die hier die Referenz zur Information an sich ist, nun einmal direkt nacheinander Werte verschiedenen Types haben. Dies ist so in strikt-typisierten Sprachen nicht möglich. Deklariert man in einer solchen Sprache eine Variable als int, so bleibt sie dies auch. In Python muss der Codeablauf dies sicherstellen, was natürlich Risiken mit sich bringt.
Bezüglich "Dies ist in vielen Bereichen aber weniger wichtig, als wie *schnell man etwas in Code ausdrücken*, sprich implementieren kann" kann ich dir ebenfalls nicht zustimmen. Üblicherweise wird Software 1x geschrieben (+ gewartet & erweitert), aber sehr oft ausgeführt. Geringe Vorteile bei der Entwicklung werden gerade in der Wirtschaft gerne von Nachteilen in der Ausführung aufgefressen.
Was nützt es, wenn man 5 Stunden beim Entwickler spart, dafür dann aber tausende Anwender täglich unnötig mit langsamer Software warten lässt?
In der Wirtschaft ist Ausführungsgeschwindigkeit oft sehr wichtig, ist doch die Ausführung der Software der Grund, warum sie überhaupt geschrieben wurde.
Schnelle Software (je nachdem, was sie ist) nutzt die Zeit der Benutzer besser (bei eCommerce Seiten kannd as Umsatz bringen!) oder braucht weniger Server.
Ich mag Python, und nutze es fast exklusiv. Aber man sollte die Kirche im Dorf lassen.
Eine Ergänzung noch zum Thema Ausführung vs. Umsetzung:
Mehr als einmal musste ich beobachten, wie jemand, der sorglos mit der Ausführungszeit einer Anwendung umging, später weit mehr Zeit in die Optimierung stecken musste, als er je bei der Entwicklung eingespart hat.
Leider werden solche Faktoren oftmals ignoriert, nacharbeiten gelten dann nicht mehr als Teil des Projektes.
Da kommen schnell völlig falsche Zahlen zur Entwicklungszeit bei heraus.
In eigentlich allen Punkten, die Du beschreibst muss ich Dir leider widersprechen - und auch viele der gängigen Meinungen tun das!
Und worin liegt hier der Widerspruch zu meiner Antwort auf die Aussage des OP? Dieser schrieb etwas von "kompilieren" - das wird Python auch. Punkt.Die Unterscheidung, die Du hier anstellst und *neu* in den Raum wirfst, ist an sich *künstlich*! Zeige mir mal eine gute und anerkannte Definition, was eine "Interpretersprache" ist! (Das verhält sich analog zum hässlichen Wort "Scriptsprache"
) Inwiefern unterscheidet sich ein Interpreter (virtuelle Maschine) von einem Prozessor? Welchen Unterschied macht das für die Praxis bzw. den Entwickler wirklich?
Der OP warf nur "kompiliert" in den Raum - das kann man sicherlich nicht einfach so stehen lassen, oder?
Nein, eben nicht! Der OP verwechselte oder ignorierte das - lies das bitte noch einmal genau nach. Python ist *stark typisiert*. Punkt. Ein Objekt vom Typ A ist ein Objekt vom Typ A und bleibt es auch. Der Unterschied besteht im Aspekt der dynamischen bzw. statischen Typisierung. Genau das habe ich auch gesagt!Oha... bei welcher Firma arbeitest Du? Da muss ich auch hinNatürlich gibt es Bereiche, bei denen man dermaßen optimieren muss, dass der reine Speed zählt und man Python (oder eine andere Sprache) nicht nutzen kann und für den Spezialfall auf anderes zurückgreifen muss. Aber das sind doch wirklich nicht die Regelfälle! (Und wir reden hier ja eigentlich auch von Kursen an der Uni!)
Vor allem muss man dazu vorher analysieren und messen, woran es denn hakt. Die stumpfe Meinung "C++ == schnellere Ausführung" ist pauschal einfach nicht wahr!
Non-Blocking Webserver werfe ich mal so als Stichwort - da nutzt die Sprache nix, sondern das Konzept dahinter bringt den Speed!
Im übrigen mag ich Python, ja, aber auch andere Sprachen.
C++ mag ich an sich nicht - aber spielte bei meiner Antwort keine Rolle! Es ging mir im ersten Teil darum, die falschen Aussagen des OP zu berichtigen.
Man muss Python nicht mögen, (es ist mir nicht verständlich, wie so sich die meisten Skriptsprachenentwickler nicht auf Implementationen wie mruby oder lua beschränken und für alles Standalone-mäßige schnelle Compiler entwickeln, ach ja, Faulheit), aber das beschränkt den Begriff kompilieren noch lange nicht auf Binärcode.
Bei Microcontroller hab ich bis jetzt nur Havard gesehen, reinrassig. Aber keiner verbietet es darauf aufbauend eine VM zu nutzen, dann gibts wieder Stanford.
Nun, Atmels AVR ist z.B. modifiziert.
Aber für kleine Microcontroller ist Laufzeitübersetzung natürlich weniger interessant.
Laut Wikipediaartikel sind auch manche PIC und andere MCs mit speziellen Befehlen fürs Laden und Speichern von Daten als Code ausgerüstet. Vermutlich ist heutzutage alles, was nicht auf ner Kartoffel läuft so.
Noch eine Ergänzung:
Der Kontext entscheidet viele Dinge bei Python, weshalb die Shell nur für Leute ist, die die Sprache nicht beherrschen.
Python zwingt dich keineswegs zum schönschreiben, nur Einrückungen sollten konsistent sein.
Lesbar ist Python nur dann, wenn man sich an die Regeln guter Programmierung hält, das fängt bei PEP8 an.
Natürlich muss man sich nicht um Speicherallokation kümmern, sollte trotzdem aber explizit sich Gedanken über den Verbrauch und Implementierung machen.
C++ hat gar keine Trennung. Wäre das der Fall gäbe es auch kein Recompiling. Da Python Objekte an Namen bindet ist das schon mal nicht vergleichbar und zudem wenn Operanden gleichen Typs sind kommt doch auch der Typ raus. Das Verhalten ist da identisch mit C++.
Wenn man CPython mit C++ vergleicht mag das stimmen, für den Rest ist das natürlich Blödsinn. Selbst wenn alles nichts bringt, liese sich auch C++ Code integrieren.
Ergo, schwer zu glauben, dass du wirklich beide Sprachen gut genug kennst, um so einen Vergleich aufzumachen.
"weshalb die Shell nur für Leute ist, die die Sprache nicht beherrschen."
Dem kann ich so nicht zustimmen.
Persönlich nutze ich die Python Shell sehr häufig, gerade weil sie vieles leichter macht.
So ist die Shell in Django-Projekten (dort bereits mit der Django Umgebung über die Manage.py vorbereitet) extrem nützlich, um die Datenbank über die Klassen der Projekte anzusprechen. Das kann sowohl das debuggen erleichtern, als auch im Alltag den Umgang mit den Daten.
Die Shell ist keine reine Spielweise, in einer größeren Umgebung ist sie ein nützlicher Anknüpfung zur Laufzeitumgebung.