ubuntuusers.de

rincewind hat geschrieben:

Chaoswind hat geschrieben:

rincewind hat geschrieben:

Chaoswind hat geschrieben:

So betrachtet, ist ausnahmslos jedes Programm ein Compiler und Interpreter.

Im Prinzip ist es auch so.

Hm, damit hast du aber eine recht einzigartige Sicht, vor allem aber eine IMHO extrem vereinfachte.

Nicht wirklich einzigartig. Analog zu Linux: alles ist eine Datei 😉

Unix, Linux erbt das Paradigma ja nur 😉
Allerdings ist das auch ein gutes beispiel. Das Datei bezieht sich ja nur auf die Handhabung. Die Physikalische repräsentation ist nicht immer wirklich eine Datei im klassischen Sinne. Ähnliche probleme seh ich bei deiner Sichtweise.

user unknown hat geschrieben:

rincewind hat geschrieben:

Chaoswind hat geschrieben:

Aber mittlerweile hat sich da ganze ja vermischt. Die Interpreter haben noch einen Compiler der vorher den Quelltext optimiert, bevor dann der Interpreter (aka Virtuelle Maschine) den Code interpretiert und die Entsprechenden Funktionen der Physikalischen Maschine aufruft.

Hier stimme ich Dir zu. Allerdings könnte ich Dir jetzt die Gleichsetzung von Interpreter und VM per aka negativ auslegen und Dich fragen, was genau Du mit den "Entsprechenden Funktionen" meinst, ich habe aber verstanden, was Du damit sagen willst.

Zumindest bei Java ist das nicht so.
Die VM bekommt den Quelltext gar nicht zu sehen, sondern optimiert den Bytecode.

Ja, meinte ich ja. Compiler übersetzt Quellcode in Byecode, Interpreter/Virtuelle Maschine macht dann sein übriges.

Chaoswind hat geschrieben:

rincewind hat geschrieben:

Nicht wirklich einzigartig. Analog zu Linux: alles ist eine Datei 😉

Unix, Linux erbt das Paradigma ja nur 😉

got me 😉
Chaoswind hat geschrieben:

Allerdings ist das auch ein gutes beispiel. Das Datei bezieht sich ja nur auf die Handhabung. Die Physikalische repräsentation ist nicht immer wirklich eine Datei im klassischen Sinne. Ähnliche probleme seh ich bei deiner Sichtweise.

Natürlich ist bei jeder abstrakten Sicht ein gewisser Unterschied zur Realität vorhanden, der Unterschied verändert sich nach Abstraktionsebene. Wie gesagt, an wirklich jedem Beispiel kann man auch beweisen, dass es nicht stimmt, es kommt darauf an, ob man den Grundgedanken des Beispiels nachvollziehen kann, denke ich.

Oh mann.

Programmiersprache
http://dict.leo.org/ende?lp=ende&lang=de&searchLoc=0&cmpType=relaxed&sectHdr=on&spellToler=on&search=compiler&relink=on
http://dict.leo.org/ende?lp=ende&lang=de&searchLoc=0&cmpType=relaxed&sectHdr=on&spellToler=on&search=interpreter&relink=on

Alle Klarheiten beseitigt? Dann geht's hier weiter www.google.com

Chaoswind hat geschrieben:

Was ist mit Lisp? Wurde da nicht auch von anfang an interpretiert?

An der MIT wurde ein Prozessor entwickelt, welcher Scheme-Code ausfuehren konnte (Das ist schon lange her, siehe SICP). Was nu?

Apollon hat geschrieben:

http://dict.leo.org/ende?lp=ende&lang=de&searchLoc=0&cmpType=relaxed&sectHdr=on&spellToler=on&search=compiler&relink=on
http://dict.leo.org/ende?lp=ende&lang=de&searchLoc=0&cmpType=relaxed&sectHdr=on&spellToler=on&search=interpreter&relink=on

compiler [comp.] der Kompiler
interpreter [comp.] der Interpreter

Jaja, ich liebe kopflose argumentationen :>

Apollon hat geschrieben:

Chaoswind hat geschrieben:

Was ist mit Lisp? Wurde da nicht auch von anfang an interpretiert?

An der MIT wurde ein Prozessor entwickelt, welcher Scheme-Code ausfuehren konnte (Das ist schon lange her, siehe SICP). Was nu?

Es gibt auch Prozessoren die Java-Code ausführen. Bei bedarf kann man auch Perl oder Python kompilieren. Und weiter? Hat mit der Thematik rein gar nichts zu tun.

Chaoswind hat geschrieben:

Es gibt auch Prozessoren die Java-Code ausführen.

Du meinst wahrscheinlich Java-Bytecode.
Unter Javacode verstehe ich was andereres, insbes. in einer Diskussion über Interpreter.

user unknown hat geschrieben:

Chaoswind hat geschrieben:

Es gibt auch Prozessoren die Java-Code ausführen.

Du meinst wahrscheinlich Java-Bytecode.
Unter Javacode verstehe ich was andereres, insbes. in einer Diskussion über Interpreter.

Gut möglich. Wie die exakt funktionieren weiss ich nicht nicht. Aber es spricht nichts dagegen das die CPUs den Code nicht auch direkt verarbeiten können.

Chaoswind hat geschrieben:

Aber es spricht nichts dagegen das die CPUs den Code nicht auch direkt verarbeiten können.

Ich würde sogar sagen: Da spricht einiges dagegen.
In den Tank eines Biodieselfahrzeugs kann ich auch ungeschälte Maiskolben stopfen, aber der Motor wäre dann doch etwas überrascht.

Da die ganze Diskussion letztendlich durch mich entstanden ist wollte ich auch noch abschließend etwas sagen. Zwar hatte ich bereits einen Post dazu geschrieben, hatte dann aber auf der Arbeit vergessen den Post abzuschicken, daher hatte das etwas länger gedauert bis ich wieder Lust hatte hier etwas rein zu schreiben.

Chaoswind hat geschrieben:

rincewind hat geschrieben:

chaoswind hat geschrieben:

sidburn hat geschrieben:

keine reine Interpretierte Sprachen wo jeder Befehl erst vor seiner Ausführung Kompiliert wird.

Was meinst du mit Ausführen? Reine Interpretersprachen kompilieren nichts, sondern rufen irgendwelche Funktionen oder (wie im extremfall Bash) sogar externe Programme/Skripte auf.

Richtig, deshalb hat Sid Burn ja auch erklärt, an welchen Punkten sich Perl/Python/Ruby von den reinen Interpretersprachen unterscheiden.

Lies das Quoting noch mal durch 😉

Ich schrieb deswegen "kompilieren" weil letztendlich alles irgendwann als Maschienencode ausgeführt wird. Wenn dir das Wort nicht passt dann benutze Bearbeiten/Analysieren/Ausführen etc. je nachdem was dir passt. Ich wollte die Unterschiede zwischen Interpreter und VM darstellen.

Und ein Interpreter liest immer nur eine Zeile ein, bearbeitet/Analysiert/kompiliert/führt die Zeilen dann aus. Und das zur Laufzeit Zeile für Zeile. Eine VM liest Bytecode und keinen Sourcecode ein. Sie bekommt also schon das bearbeitete/analysierte/kompilierte was auch immer.

Was nun genau richtig ist, hängt davon ab auf welcher Ebene man das ganze betrachtet. Dazu habt ihr ja das Beispiel mit "Alles ist eine Datei" genannt.

Allerdings ist das auch ein gutes beispiel. Das Datei bezieht sich ja nur auf die Handhabung. Die Physikalische repräsentation ist nicht immer wirklich eine Datei im klassischen Sinne. Ähnliche probleme seh ich bei deiner Sichtweise.

Probleme gibt es nicht wirklich in der Sichtweise. Es gibt halt unterschiedliche Ebenen.

Wenn ich sage /dev/hda oder /dev/ttyS0 ist eine Datei dann stimmt das. Auch wenn sich auf einer anderen Ebene dahinter eine Festplatte oder eine Serielle Schnittstelle befinden. Wenn du nun selber ein Programm Programmierst dann muss dich auch nicht Interessieren was wirklich hinter /dev/hda steckt. Für dich ist es eine Datei und fertig, und du hast darauf Zugriff wie eine Datei.

Ich lese aus /dev/ttyS0 genauso meine Daten aus wie aus /home/sidburn/cooler_film.mpeg. Das was dahinter steckt muss mich nicht Interessieren. Wenn nun jemand sagt das eine ist eine Serielle Schnitstelle und das andere ist eine Datei, dann hat er recht. Bedeutet aber nicht das damit gleichzeitig die Sichtweise "Alles ist eine Datei" falsch ist. Derjeniege der sagt beides sind Dateien hat genauso recht. Nur halt auf einer anderen Ebene.

Wenn ich sage über einen Netzwerk gehen nur Bits, dann ist das genauso richtig als wenn jemand sagt das sind aber "IP Frames" oder "Ethernet Packete" und nicht nur Bits. Für das Netzwerk gibt es deswegen das TCP/IP Modell, oder das OSI-Modell (das ich nicht mag), damit man immer klar stellen kann auf welcher Ebene man gerade Spricht. Bei Computer gibt es sowas anscheind nicht, von daher kann es hier immer wieder zu problemen führen. Wenn man aber versucht den "Sinn" hinter einen Satz zu verstehen, und nicht simpel einfach Wort für Wort liest sollte es hoffentlich klar werden, was gemeint war.

chaoswind hat geschrieben:

sid burn hat geschrieben:

Da man aber halt den Sourcecode weiter gibt, wird es immer noch als Skriptsprache abgestempelt. Wenn man die Technik dahinter genauer betrachtet ist es eigentlich falsch. Allerdings sage ich dazu auch Trotzdem Skriptsprache, weil es halt als Merkmal trägt den Sourcecode weiter zu geben.

Skriptsprache wird mittlerweile vor allem für die abstraktionsebene benutzt. Steht ja schon im Wikipedia-Artikel. Die Sprachen sind einfacher und verzichten auf verschiedene kontrollmöglichkeiten die eine schnelle Entwicklung ausbremsen.

Halt ich für eine Total Dumme definition für "Skriptsprachen", genau das selbe eine Skriptsprache über ihre "Kontrollmöglichkeiten" zu definieren. Auch wenn ich anfangs nicht wuste was du damit genau meintest.
chaoswind hat geschrieben:

Keine Variablendeklaration, keine zeitaufwendige Typisierung, etc. Alles halt was die Arbeit verlangsamt und fuer die Entwicklung an sich nicht notwendig ist.

Ist deswegen Dumm, weil es eine variablendeklaration in Perl gibt. Wenn du einfach "use strict;" am anfang schreibst muss du variablen vor derren Verwendung deklarieren und es gibt bereits beim Kompilieren des Skriptes einen Fehler, wenn du eine variable benutzt die du vorher nicht deklariert hast. (Ich denke das wird es auch in Python/Ruby geben). Dieses Verhalten wird sogar ab Perl6 Das Default verhalten sein!

Zur Typisierung. Ich selber sehe jetzt in der Typisierung keine Vorteile. Jedenfalls bei der Verwendung. Vorteile gibt es bei der Performance. Wenn du also die Kontrollmöglichkeiten soweit ausdehnst indem du damit meinst die Performance besser zu Kontrollieren. Soetwas gibt es bei Perl5 z.B. noch nicht, wird aber mit Perl6 hinzu kommen. Dort wirst du sagen können das eine Variable von Typ int sein soll. Das du ein Array erzeugst mit 100 Elementen und jedes Element 5 Byte groß sein soll etc.

Trotzdem schreibst du es immer noch als Sourcecode und führst es noch immer so aus wie bei Perl5. Von daher werde ich, und viele andere es eben immer noch als Skriptsprache bezeichnen. Für mich ist Skriptsprache einfach nur die Definition: Weitergabe und "direktes" ausführen des Sourcecodes, ohne das du es vorher Kompilieren musst etc.

Damit es nicht weiter zu Diskussionen kommt:
Compiler = Programm das einen Sourcecode in eine beliebige Zielsprache übersetzt.
Interpreter = Führt Zeile für Zeile nacheinander aus.
Virtuelle Maschiene = Führt einen Bytecode aus.

Perl/Python = ist ein Compiler+VM. Es Kompiliert den Sourcecode und führt dann den Bytecode mit der VM aus. Perl/Python kann nicht direkt Sourcecode ausführen, und auch nicht Interpretieren.

Java = Compiler & VM getrennt. Compilierung Manuell, und ausführung explizit mit der VM.

Mit Ruby habe ich mich übriges getäuscht. Es benutzt keinen Bytecode, sondern so wie es ausschaut wird es Interpretiert. Hätte ich eigentlich von Ruby nicht erwartet, vor allem da es ja doch schon etwas neuer ist.

user unknown hat geschrieben:

Chaoswind hat geschrieben:

Aber es spricht nichts dagegen das die CPUs den Code nicht auch direkt verarbeiten können.

Ich würde sogar sagen: Da spricht einiges dagegen.
In den Tank eines Biodieselfahrzeugs kann ich auch ungeschälte Maiskolben stopfen, aber der Motor wäre dann doch etwas überrascht.

Sicher, und wenn ich Java-Bytecode direkt auf eine unvorbereitetet CPU loslasse, wird die auch zicken machen.
Prinzipiell ist es keine grosse Kunst so einer Java-CPU beizubringen statt dem Bytecode, auch den Quellcode zu nutzen. Ob das sinnvoll ist, keine ahnung. Ob das Vor- oder Nachteile hat, keine ahnung. Ob das gemacht wird, erst recht keine ahnung.

sidburn hat geschrieben:

Und ein Interpreter liest immer nur eine Zeile ein, bearbeitet/Analysiert/kompiliert/führt die Zeilen dann aus. Und das zur Laufzeit Zeile für Zeile. Eine VM liest Bytecode und keinen Sourcecode ein. Sie bekommt also schon das bearbeitete/analysierte/kompilierte was auch immer.

Sorry, aber das halt ich für kompletten nonsens. Eine VM liest genauso ihren Code ein wie ein Quellcode-Interpreter. Beides sind Dateien mit Struktorierten Anweisungen in einer Spezifischen Sprache. Quellcode ist lediglich fuer den Menschen lesbarer, waehrend Bytecode ganz klar auf eine spezifische Maschine optimiert ist. Der ganze Technische Vorgang dahinter, hat damit rein gar nichts zu tun. Allgemein betrachtet ist eine VM auch nicht mehr als ein Interpreter fuer Bytecode.

sidburn hat geschrieben:

Allerdings ist das auch ein gutes beispiel. Das Datei bezieht sich ja nur auf die Handhabung. Die Physikalische repräsentation ist nicht immer wirklich eine Datei im klassischen Sinne. Ähnliche probleme seh ich bei deiner Sichtweise.

Probleme gibt es nicht wirklich in der Sichtweise. Es gibt halt unterschiedliche Ebenen.

Wenn ich sage /dev/hda oder /dev/ttyS0 ist eine Datei dann stimmt das. Auch wenn sich auf einer anderen Ebene dahinter eine Festplatte oder eine Serielle Schnittstelle befinden. Wenn du nun selber ein Programm Programmierst dann muss dich auch nicht Interessieren was wirklich hinter /dev/hda steckt. Für dich ist es eine Datei und fertig, und du hast darauf Zugriff wie eine Datei.

Tja, solange bis ich probiere sie zu löschen. Und ganz interessant wird es wenn es auf ein anderes Medium oder zumindest eine andere Partition kopieren oder gar verschieben will. Da sich dahinter eben doch nur ein fingiertes Virtuelles Objekt befindet, gibt es grenzen bei denen das Paradigma nicht mehr funktioniert.

sidburn hat geschrieben:

chaoswind hat geschrieben:

Keine Variablendeklaration, keine zeitaufwendige Typisierung, etc. Alles halt was die Arbeit verlangsamt und fuer die Entwicklung an sich nicht notwendig ist.

Ist deswegen Dumm, weil es eine variablendeklaration in Perl gibt. Wenn du einfach "use strict;" am anfang schreibst muss du variablen vor derren Verwendung deklarieren und es gibt bereits beim Kompilieren des Skriptes einen Fehler, wenn du eine variable benutzt die du vorher nicht deklariert hast. (Ich denke das wird es auch in Python/Ruby geben). Dieses Verhalten wird sogar ab Perl6 Das Default verhalten sein!

use strict ist eine option, kein zwang. Ich jede Sprache mehr oder weniger aufwendig in ihren möglichkeiten verschaerfen, aber ich kann in der regel keine Sprache in ihren Kontrollmechanismen lockern ohne den Compiler/Interpreter umzuschreiben. Übrigens ist use strict die ausnahme von der Regel.

sidburn hat geschrieben:

Zur Typisierung. Ich selber sehe jetzt in der Typisierung keine Vorteile. Jedenfalls bei der Verwendung. Vorteile gibt es bei der Performance.

Anders rum. In der Performance bringt Typisierung nach diversen Studien wohl minimal bis gar nichts (wobei das sicherlich auch von der Sprache und Umgebung abhaengt). Dafuer bringt es dem Entwickler eine ganze menge weil es saubere Schnittstellen erlaubt. Ich kann mit wenig aufwand und Code, sehr fein granulierte Strukturen definieren. In Sprachen ohne Typen oder ohne Zwangstypen ist sowas ein mittler bis grosser aufwand.

sidburn hat geschrieben:

Für mich ist Skriptsprache einfach nur die Definition: Weitergabe und "direktes" ausführen des Sourcecodes, ohne das du es vorher Kompilieren musst etc.

C/C++ sind damit per definition Skriptsprachen. Denn dafuer existieren Interpreter.

BTW Bezüglich Ruby: dort ist AFAIK fuer Version 2.0 eine VM geplant. So ein ding muss schliesslich gut geplant werden, wie man an Parrot sieht :>

Chaoswind hat geschrieben:

sidburn hat geschrieben:

Zur Typisierung. Ich selber sehe jetzt in der Typisierung keine Vorteile. Jedenfalls bei der Verwendung. Vorteile gibt es bei der Performance.

Anders rum. In der Performance bringt Typisierung nach diversen Studien wohl minimal bis gar nichts (wobei das sicherlich auch von der Sprache und Umgebung abhaengt). Dafuer bringt es dem Entwickler eine ganze menge weil es saubere Schnittstellen erlaubt. Ich kann mit wenig aufwand und Code, sehr fein granulierte Strukturen definieren. In Sprachen ohne Typen oder ohne Zwangstypen ist sowas ein mittler bis grosser aufwand.

Könntest Du uns ein paar Links zu den diversen Studien geben? Das kann ich so nämlich nicht nachvollziehen.
Meiner Erfahrung nach bringt es erhebliche Performanceunterschiede, wenn die Typisierung dem Anwendungsfall entsprechend vorgenommen wird. Meiner Meinung nach ist das auch einer der Gründe, warum es die Typisierung überhaupt gibt.
Gerade bei Schnittstellenprogrammierung kam es in meiner bisherigen Praxis oft zu Problemen mit Typkonvertierungen. Vielleicht haben wir hier unterschiedliche Definitionen von "sauberen Schnittstellen", weshalb ich mich über eine Erklärung freuen würde.

EDIT: Die restlichen Punkte lasse ich aus momentanen akuten Zeitmangel unkommentiert, vielleicht später mehr.

Tja, solange bis ich probiere sie zu löschen. Und ganz interessant wird es wenn es auf ein anderes Medium oder zumindest eine andere Partition kopieren oder gar verschieben will. Da sich dahinter eben doch nur ein fingiertes Virtuelles Objekt befindet, gibt es grenzen bei denen das Paradigma nicht mehr funktioniert.

Log dich mit root Rechten ein. "hda" ist bei mir das CD-Rom Laufwerk.

mv /dev/hda /

Damit ist "hda" unter / gewesen.

eject /hda

Hat immer noch mein CD-Rom Laufwerk geöffnet

rm /hda

CD-Rom Laufwerk ist weg.

Was meinst du also genau?

dd kann nur mit Dateien umgehen

dd if=/dev/null of=/dev/hde

Macht seine Sache ebenso, und überschreibt hde komplett mit Nullen, obwohl es eine Festplatte ist.

Tja, solange bis ich probiere sie zu löschen. Und ganz interessant wird es wenn es auf ein anderes Medium oder zumindest eine andere Partition kopieren oder gar verschieben will. Da sich dahinter eben doch nur ein fingiertes Virtuelles Objekt befindet, gibt es grenzen bei denen das Paradigma nicht mehr funktioniert.

/home ist bei mir eine andere Partition als /

mv /dev/hdc /home

Ging bei mir!

cp /dev/hdg /home/sidburn/blub

Fängt an die Datei nach /home/sidburn/blub zu Kopieren.
Beziehungsweise den Inhalt der Festplatte der dahinter steckt.

Sorry, aber das halt ich für kompletten nonsens. Eine VM liest genauso ihren Code ein wie ein Quellcode-Interpreter. Beides sind Dateien mit Struktorierten Anweisungen in einer Spezifischen Sprache. Quellcode ist lediglich fuer den Menschen lesbarer, waehrend Bytecode ganz klar auf eine spezifische Maschine optimiert ist. Der ganze Technische Vorgang dahinter, hat damit rein gar nichts zu tun. Allgemein betrachtet ist eine VM auch nicht mehr als ein Interpreter fuer Bytecode.

Ich glaube das mit den Ebenen wirst du nie verstehen.

Deine Aussage ist ungefähr das selbe als wenn du sagst das IP und HTTP identisch ist, weil bei beiden am ende BITs heraus kommen.

use strict ist eine option, kein zwang.

und?

Ich jede Sprache mehr oder weniger aufwendig in ihren möglichkeiten verschaerfen, aber ich kann in der regel keine Sprache in ihren Kontrollmechanismen lockern ohne den Compiler/Interpreter umzuschreiben. Übrigens ist use strict die ausnahme von der Regel.

Ist "use strict" jetzt die Ausnahme weil es deine Aussage wiederlegen würde?

Also Perl ist deswegen eine Skriptsprache weil es keine Kontrollmöglichkeiten hat. Du selber sagst aber auch gleich das du keinen Compiler/Interpreter kennst wo du eine Sprache ändern kannst. Sprich du hast in keiner Sprache Kontrollmöglichkeiten, also ist auch C/C++ z.B. eine Skriptsprache?

"strict" selber ist ein Pragma das die Behandlung des Codes verändert. Was ist mit den anderen 22 Pragmas die auf einer gewissen Weise die bearbeitung deines Codes verändern? Auch alle ungültig?

"attributes", "autouse", "base", blib", "bytes", "charnames", "constant", "diagnostics", "fields", "filetest", "integer", "less", "lib", "locale", "open", "overload", "re", "sigtrap", "strict", "subs", "vars", "warnings"

Anders rum. In der Performance bringt Typisierung nach diversen Studien wohl minimal bis gar nichts (wobei das sicherlich auch von der Sprache und Umgebung abhaengt). Dafuer bringt es dem Entwickler eine ganze menge weil es saubere Schnittstellen erlaubt. Ich kann mit wenig aufwand und Code, sehr fein granulierte Strukturen definieren. In Sprachen ohne Typen oder ohne Zwangstypen ist sowas ein mittler bis grosser aufwand.

Ich weiß zwar nicht wie du "saubere" Schnitstellen definierst und was "dreckige" sind, aber ich lasse das mal so stehen. Die High-Level Sprachen machen eine bearbeitung leichter, das war es aber auch. Für das "leichter" erkaufst du dir aber Performance. Da immer auf den Typ geprüft werden muss, es muss immer ein Typecast gemacht werden, je nachdem welchen Typ du brauchst etc. Und das kostet sehr wohl performance, auch in C/C++. Wenn du direkt sagst das du nur Integer hast können verschiedene Optimierungen für Integer greifen. Und genauso wird es auch in Perl6 laufen. Eine variable als Integer deklariert, damit wird deine Rechenoperation schneller sein, als wenn du diese als String deklarierst, weil dann ständig ein Typecast gemacht werden muss.

Wenn ich ein Array mit 100 Elementen mit je 5 Bytes erzeuge, dann kann mein Programm direkt 500Bytes am Stück erzeugen, und kann direkt drauf zugreifen. Ein Normales Perl Array wird im Speicher durch ein Array dargestellt das die Speicheradressen von Strukturen enthält. Es muss also dieses auslesen, dann zur Struktur springen, und ggf- noch ein Typecast machen. Das ist definitiv langsamer! Und eine direkte Typisierung kann dir immense Vorteile bringen.

C/C++ sind damit per definition Skriptsprachen. Den dafuer existieren Interpreter.

Wenn ich C/C++ im Verbund mit diesem "Interpreter" benutze dann ja. Was ist daran verkehrt? C/C++ an sich ist nur eine Sprache. Es hängt davon ab was ich damit mache.

Bjarne Stroustrup, Die C++ Programmiersprache, 2. Auflage, Adddisson Wesley 1994, S. 435 hat geschrieben:

Das Laufzeitverhalten bei statischer und dynamischer Typüberprüfung kann sich signifikant unterscheiden, normalerweise um einen Faktor zwischen 3 und 10.

Aus dem Zusammenhang verstehe ich dieses Zitat aber so, daß unterschiedliche Implementierungen mit C++ verglichen werden.
Einen generellen Unterschied für eine Sprache anzugeben, die nur eine der beiden Möglichkeiten bietet, ist unmöglich, weil man schlicht nicht sagen kann, wie schnell es wäre, wenn es anders wäre.
Es gibt ja auch keine endgültigen Implementierungen von Compilern, Interpretern, Linkern und VMs.
Diese entwickeln sich einerseits weiter, und andererseits ändert sich auch die Hardware, so daß ein Vergleich auf einem anderen Prozessor wieder anders ausgehen kann und wird.

Als wichtigsten Grund strenge Typisierung in C++ zu verwenden nennt B.S. die Möglichkeit, Fehler zur Compilezeit und nicht erst zur Laufzeit zu finden, aber auch, daß die Typisierung eine Schnittstellendokumentation ist, und so die Entwurfsphase und die Kommunikation von Entwicklergruppen unterstützt.
Letzteres würde dafür sprechen, daß größere Projekte eher mit Sprachen realisiert werden, die starke Typisierung einsetzen.
chaoswind hat geschrieben:

Prinzipiell ist es keine grosse Kunst so einer Java-CPU beizubringen statt dem Bytecode, auch den Quellcode zu nutzen.

Wenn's keine große Kunst ist, dann mach doch mal.
Da fällt einem doch nichts mehr ein...

Chaoswind hat geschrieben:

Apollon hat geschrieben:

http://dict.leo.org/ende?lp=ende&lang=de&searchLoc=0&cmpType=relaxed&sectHdr=on&spellToler=on&search=compiler&relink=on
http://dict.leo.org/ende?lp=ende&lang=de&searchLoc=0&cmpType=relaxed&sectHdr=on&spellToler=on&search=interpreter&relink=on

compiler [comp.] der Kompiler
interpreter [comp.] der Interpreter

Jaja, ich liebe kopflose argumentationen :>

Haettest Du einen Kopf, dann wuerdest Du alle durchlesen. Ein Wort ist oft mehrdeutig, was Du sicherlich auch weisst.

user unknown hat geschrieben:

Chaoswind hat geschrieben:

Aber es spricht nichts dagegen das die CPUs den Code nicht auch direkt verarbeiten können.

Ich würde sogar sagen: Da spricht einiges dagegen.
In den Tank eines Biodieselfahrzeugs kann ich auch ungeschälte Maiskolben stopfen, aber der Motor wäre dann doch etwas überrascht.

Wieso soll es nicht moeglich sein, einen Prozessor zu entwickeln, der alles was ein Kompiler macht in Hardware implementiert und es dann ausfuehrt?

So eine Diskussion gab es vor kurzem hier: http://www.spieleprogrammierer.de/phpBB2/viewtopic.php?t=5729&postdays=0&postorder=asc&start=15.
Da meinte einer doch in der Tat eine KLARE Grenze zwischen Programmier- und Skriptsprachen ziehen zu koennen.
Er wurde zurechtgewiesen mit folgendem Link: http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht3Ht/begriff_programmiersprache_de
Das ist die ISO-Definition einer Programmiersprache.

user unknown hat geschrieben:

chaoswind hat geschrieben:

Prinzipiell ist es keine grosse Kunst so einer Java-CPU beizubringen statt dem Bytecode, auch den Quellcode zu nutzen.

Wenn's keine große Kunst ist, dann mach doch mal.
Da fällt einem doch nichts mehr ein...

Es ist auch theoretisch keine große Kunst dies zu tun (jedenfalls wenn man in der Lage ist einen "normalen" Prozessor zu bauen und einen compiler zu entwickeln).
Es wird dann halt nur unglaublich komplex und irgendwie verschwenderisch.

Apollon hat geschrieben:

So eine Diskussion gab es vor kurzem hier: http://www.spieleprogrammierer.de/phpBB2/viewtopic.php?t=5729&postdays=0&postorder=asc&start=15.
Da meinte einer doch in der Tat eine KLARE Grenze zwischen Programmier- und Skriptsprachen ziehen zu koennen.
Er wurde zurechtgewiesen mit folgendem Link: http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht3Ht/begriff_programmiersprache_de
Das ist die ISO-Definition einer Programmiersprache.

Also ich glaube hier unterscheidet keiner Programmiersprache mit Skriptsprache.

Für mich persönlich ist jede Skriptsprache auch gleichzeitig eine Programmiersprache, nur mit der eigenheit das die die Programme über ihren Sourcecode weiter gegeben werden, und darüber auch ausgeführt werden. (Auch wenn bei Perl/Python mehr im Hintergrund passiert).

Das ist für mich das selbe wie das eine Methode letztendlich auch nur eine Funktion ist. Der Unterschied aber ist, dass sie innerhlab einer Klasse ist. Auf die Unterschiede kommt es drauf an, und daher der neue Name.

Und so wie ich das hier herausgelesen habe, hat bisher noch keiner gesagt das Perl/Python/Ruby/PHP/Java keine Programmiersprache wäre.