ubuntuusers.de

rincewind hat geschrieben:

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.

Da ich momentan mit ISDN via Call-by-Call unterwegs bin, hab ich nicht die notwendige Anbindung um die Links zu Studien zu sammeln. Aber kannst dich mal auf planet.python.org(?) umsehen. Da tauchen alle Monate mal irgendwelche Entwickler auf welche für oder gegen Typisierung argumentieren und dann tauchen auch entsprechende Links auf. Die Performanceverbesserungen liegen da immer um die 5% im günstigsten Fall. Woran es liegt, schwer zu sagen, aber es ist wohl anzunehmen das die 30 Jahre Entwicklung seitdem sich streng Typisierte Sprachen durchgesetzt haben, ein bisschen mehr als plastischere Spiele hervorbrachten 😉

user unknown hat geschrieben:

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

Kein problem. Ich schmelz gleich mal die Goldzaehne meine Oma ein und schnitz mir mit einem Zahnstocher die CPU.

Apollon hat geschrieben:

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

Haettest du deinen Kopf benutzt waere dir aufgefallen das wir die wörtliche Übersetzung fuer Compiler und Interpreter schon öfters erwaehnten. Aber scheinbar hast du den Thread entweder nicht gelesen, oder nicht verstanden. Mit stumpfsinnigen Übersetzungen eines unspezialisierten Wörterbuchs löst man jedenfalls rein gar nichts.

Apollon hat geschrieben:

Da meinte einer doch in der Tat eine KLARE Grenze zwischen Programmier- und Skriptsprachen ziehen zu koennen.

Ich hab die diskussion jetzt nicht gelesen, daher glaub ich dir deine aussage mal. Aber abgesehen davon, was juckt mich das? Erstens hab ich nie behauptet das Skriptsprachen keine Programmiersprachen sind. Zweitens halte ich so einen vesuche für puren Schwachsinn, da Skriptsprachen einfach nur eine spezielle art von Programmiersprache sind. Und drittens hat der Einwand rein gar nichts mit dem Thema zu tun.

Apollon hat geschrieben:

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.

Und wir wissen ja wie unfehlbar und allwissend die ISO ist :>
SCNR

Sid Burn hat geschrieben:

Ich glaube das mit den Ebenen wirst du nie verstehen.

Vielleicht, vielleicht hast du aber auch nicht verstanden das es einfach quatsch ist.

Sid Burn hat geschrieben:

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.

Das zumindest ist auf jedenfall quatsch.

Sid Burn hat geschrieben:

use strict ist eine option, kein zwang.

und?

Skriptsprachen zeichnen sich dadurch aus das sie weniger zwänge haben. Da use strict eine option ist, passt Perl ohne weiteres in diese definition. Um das nochmal verständlich zu machen: es geht nicht darum was eine Sprache erlaubt, sondern zu was einem eine Sprache zwingt.

Sid Burn hat geschrieben:

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?

Nein, weil die meisten Skriptsprachen (vermutlich sogar alle ausser Perl) etwas wie use strict nicht kennen (zumindest offiziell).

Sid Burn hat geschrieben:

Du selber sagst aber auch gleich das du keinen Compiler/Interpreter kennst wo du eine Sprache ändern kannst.

Lies dir mein geschreibsel noch mal durch. Das hab ich nicht geschrieben.

Sid Burn hat geschrieben:

Ich weiß zwar nicht wie du "saubere" Schnitstellen definierst und was "dreckige" sind,

Saubere Schnittstellen nehmen nur fest definierte Daten an. Unsaubere nehmen jeden müll an und verhalten sich dann merkwürdig. Diese merkwürdigkeiten herauszufinden kostet am ende unglaublich viel Zeit.

Sid Burn hat geschrieben:

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++.

Das ist ein problem Streng typisierter Sprachen.

Sid Burn hat geschrieben:

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.

Jetzt würde ich sogar vermuten, das ist ein problem von Perl :>

Sid Burn hat geschrieben:

Und eine direkte Typisierung kann dir immense Vorteile bringen.

Kann, muss aber nicht. Das ist der knackpunkt.

Sid Burn hat geschrieben:

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.

Du widersprichst dir gerade erheblich. Entweder eine Sprache ist Skriptsprache, oder nicht. Oder willst du ernsthaft behaupten der Status wird ganz individuell nach jedem einzelnen Anwendungsfall verliehen? Wenn Hänschen seine Perl-Programme also kompiliert, Margot sie aber lieber im Interpreter laufen laesst, dann ist Perl mal Skript, mal Nicht-Skriptsprache?

Apollon hat geschrieben:

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

Ich habe nicht behauptet, es sei nicht möglich einen solchen Prozessor zu entwickeln.
Dieser Diskussionszweig begann damit, daß ich korrigierend behauptet habe, daß die CPUs, die Javacode direkt ausführen können, Java-Bytecode und nicht Sourcecode ausführen.
Das - könnte man sagen - sei doch selbstverständlich, aber da es im ganzen Thread um die Abgrenzung zw. Interpreter und Compiler ging, wollte ich diesen kleinen Mangel an Präzision nicht durchgehen lassen.
Dann wurde behauptet, daß es keinen Grund gäbe, wieso die CPUs nicht auch Quellcode verarbeiten können:
Chaoswind hat geschrieben:

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

Von anderen, imaginären CPUs, die erst noch konstruiert werden müßten, war bis dahin nicht die Rede.
Und es wird auch nicht der Konjunktiv benutzt ('verarbeiten könnten'), sondern der Infinitiv - die Rede ist also von CPUs die es bereits können.
Das steht zumindest da.

Diese Lesart wird weiterhin gestützt durch das, was chaoswind dann weiter zu sagen hatte:

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

Es ist offenbar von diesen speziellen Java-CPUs die Rede, denen man aber auch beibringen kann, den Quellcode zu verarbeiten.
Das wirft meine Vorstellungen von CPUs ziemlich über den Haufen, aber da ich keine derartige CPU habe lasse ich mir gerne vorführen, wie man einer solchen CPU beibringt, Quellcode auszuführen. Das ist keine große Kunst.
Man lernt ja nie aus.

Neueren Verlautbarungen zur Folge benötigt man jetzt aber doch Gold und einen Zahnstocher, um solch eine CPU erst noch zu produzieren.

Jim Panse und Du behaupten/behauptest, es sei keine große Kunst (aber äußerst komplex) bzw. theoretisch möglich eine CPU zu entwickeln, die Quellcode nativ ausführt.
Daß es prinzipiell unmöglich ist habe ich nie behauptet.
Zwischen 'prinzipiell möglich' und 'keine große Kunst' sehe ich aber immer noch einen erheblichen Unterschied.

Skriptsprachen zeichnen sich dadurch aus das sie weniger zwänge haben. Da use strict eine option ist, passt Perl ohne weiteres in diese definition. Um das nochmal verständlich zu machen: es geht nicht darum was eine Sprache erlaubt, sondern zu was einem eine Sprache zwingt.

Ne, dass ist Quatsch. Hast du noch so ein paar Sonderregeln damit du alles irgendwie zurecht biegen kannst? Und deine definition ist total wirsch.

Ab welchen Grad von zwang und nicht zwang ist es den genau Skript- und wann nciht mehr Skriptsprache? Python zwingt mich meinen Code eingerückt zu Schreiben, C/C++ nicht. Da mich C/C++ zu weniger zwingt ist es jetzt eine Skriptsprache, und weil mich Python zu mehr zwingt ist es keine? Genau das ist total Sinnlos.

Genau mit dieser definition kann man überhaupt nichts festlegen. Du müsstest schon die Punkte nennen und noch eingewichten. Perl zwingt dich auch nicht runde Klammern bei einer Funktion zu schreiben. Ist das jetzt schlimmer als keine Typisierung? Ich muss auch nicht in Perl OOP Programmieren und kann bei Prozedural bleiben, ist das noch schlimmer? Und hier habe ich genau wie bei "use strict" wieder die freie wahl. Bedeutet das nun das ich gar nicht OOP und auch nicht Prozedural Programmieren kann, weil ich dazu nicht gezwungen wurde? Den das ganze ist ja nur eine "Option".

Also wenn ich Quatsch schonmal gelesen habe. Dann genau das hier.

chaoswind hat geschrieben:

sid burn hat geschrieben:

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.

Jetzt würde ich sogar vermuten, das ist ein problem von Perl :>

Die meisten Skriptsprachen die bisher existieren besitzen keine Typisierung, daher muss unweigerlich ein Typecast vorgenommen werden. Perl6 wird es dir erlauben deine Variablen doch zu Typisieren und Vorteile in der Performance zu erzielen, was ist daran schlecht? Wenn du es nicht möchtest kannst du ja weiterhin untypisierte Variablen benutzen.

Du widersprichst dir gerade erheblich. Entweder eine Sprache ist Skriptsprache, oder nicht. Oder willst du ernsthaft behaupten der Status wird ganz individuell nach jedem einzelnen Anwendungsfall verliehen? Wenn Hänschen seine Perl-Programme also kompiliert, Margot sie aber lieber im Interpreter laufen laesst, dann ist Perl mal Skript, mal Nicht-Skriptsprache?

Nein, ich wiederspreche mir nicht. Das Problem ist wie du C/C++ definierst.

Was ist C/C++/Perl/Java etc. den? letztendlich sind es nur Regeln wie du etwas schreiben musst damit dein geschriebenes ein Compiler oder ein Interpreter versteht. C/C++/Perl/Java selber ist nicht eine Skriptsprache, keine Interpretierte Sprache und auch keine kompilierte Sprache.

Wenn du einen Interpreter entwickelst der eben die selben Syntax Regeln hat wie C/C++ dann kannst du auch C/C++ Sourcecode Interpretieren. Entwickelst du einen Compiler kannst du es Kompilieren. C/C++ sind nur Regeln eine Gramatik die vorgegeben ist. Es selber kann man eigentlich nicht als "Interpretierte" oder "kompilierte" Sprache bezeichnen.

Allerdings macht man es trotzdem, eben je nachdem was man am häufigsten verwendet. Perl Source Code wird immer direkt von "perl" ausgeführt. (Perl = bezeichnet die Sprache | perl = mit kleinem "p" den Interpreter/VM ) Und eben als Sourcecode weitergegeben. Daher eben Skriptsprache. C/C++ lasse ich so gut wie immer von einem Compiler in Maschienencode Kompilieren. Daher sagt man eben auch das C/C++ eine kompilierte Sprache ist. Bzw. ich daraus native Binaries erzeuge.

Es gibt immer ein "aber" und du kannst dir die widelsten Konstrukte überlegen. Wenn man das aber macht dann endet es in einer endlos weden Diskussion ohne Sinn.

Du kannst über die Sprache selber eigentlich überhaupt nicht festlegen ob es Interpretiert oder Kompiliert wird. Und letztendlich kannst du zu jeder Sprache auch einfach einen Interpreter oder Compiler entwickeln wenn du es möchtest. Da die Sprache wie gesagt nur Syntax Regeln sind.

Du kannst also weiterhin zu allem ein "aber" suchen, und die nächsten 10 jahre weiter diskutieren, oder einfach die häufigste Benutzung gelten lassen. Wie du dich entscheidest ist mir ziemlich egal, da es nichts an den aktuellen Umständen ändern wird.

Chaoswind hat geschrieben:

Apollon hat geschrieben:

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

Haettest du deinen Kopf benutzt waere dir aufgefallen das wir die wörtliche Übersetzung fuer Compiler und Interpreter schon öfters erwaehnten. Aber scheinbar hast du den Thread entweder nicht gelesen, oder nicht verstanden. Mit stumpfsinnigen Übersetzungen eines unspezialisierten Wörterbuchs löst man jedenfalls rein gar nichts.

Ich habe ja schon geschrieben, dass Woerter durchaus mehrdeutig sein koennen. Also nochmal fuer dich:
compiler [comp.] : der Übersetzer
interpreter [comp.] : der Übersetzer

Chaoswind hat geschrieben:

Apollon hat geschrieben:

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.

Und wir wissen ja wie unfehlbar und allwissend die ISO ist :>
SCNR

Hmm... Also an der Uni haben uns die Profs das genauso beigebracht. Aber offensichtlich liegen sie alle falsch und Du weisst es besser. Dann lass uns doch aus deinem reichen Wissensfundus schoepfen und klaer uns bitte auf. Wenigstens mich, da hier scheinbar jeder ausser mir es bereits weiss. Teile uns/mir die richtige Definition einer Programmiersprache mit. Moeglicherweise wird dann sogar die ISO ihren Fehler einsehen und deine Definition uebernehmen.

user unknown hat geschrieben:

Apollon hat geschrieben:

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

Ich habe nicht behauptet, es sei nicht möglich einen solchen Prozessor zu entwickeln.

Hat sich fuer mich so angelesen. Sorry fuer das Missverstaendniss.

user unknown hat geschrieben:

Diese Lesart wird weiterhin gestützt durch das, was chaoswind dann weiter zu sagen hatte:

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

Es ist offenbar von diesen speziellen Java-CPUs die Rede, denen man aber auch beibringen kann, den Quellcode zu verarbeiten.
Das wirft meine Vorstellungen von CPUs ziemlich über den Haufen, aber da ich keine derartige CPU habe lasse ich mir gerne vorführen, wie man einer solchen CPU beibringt, Quellcode auszuführen. Das ist keine große Kunst.
Man lernt ja nie aus.

Es ist auch keine grosse Kunst. Allerdings stehen der Arbeits- und Kostenaufwand in keiner Relation zum Nutzen einer solchen CPU. Daher wird das auch nicht gemacht. Als Forschungsprojekt wurde es jedoch durchgefuehrt. Das schrieb ich aber schon (Scheme-CPU).

Und das ist die genaue Definition der Sprache C in Backus-Naur-Form: http://lists.canonical.org/pipermail/kragen-hacks/1999-October/000201.html. Es faellt mir nun schwer zu entscheiden, ob C eine Skriptsprache ist oder nicht.

@ Sid Burn. Vor allem in der OpenSource-Welt werden Programme sehr oft als Quelltext weitergegeben, unabhaengig davon, ob sie nun kompilliert werden muessen vor ihrer Ausfuehrung oder nicht. Ebenso kann man z.B. Python-Programme als *.pyc/*.pyo weitergeben. Daher halte ich deine Unterscheidung fuer nicht sinnvoll (mal abgesehen davon, dass ich da jegliche Unterscheidung fuer sinnlos halte).

Apollon hat geschrieben:

Und das ist die genaue Definition der Sprache C in Backus-Naur-Form: http://lists.canonical.org/pipermail/kragen-hacks/1999-October/000201.html. Es faellt mir nun schwer zu entscheiden, ob C eine Skriptsprache ist oder nicht.

@ Sid Burn. Vor allem in der OpenSource-Welt werden Programme sehr oft als Quelltext weitergegeben, unabhaengig davon, ob sie nun kompilliert werden muessen vor ihrer Ausfuehrung oder nicht. Ebenso kann man z.B. Python-Programme als *.pyc/*.pyo weitergeben. Daher halte ich deine Unterscheidung fuer nicht sinnvoll (mal abgesehen davon, dass ich da jegliche Unterscheidung fuer sinnlos halte).

Okay, vielleicht sollte ich noch hinzufügen das der Code weiterhin mit hilfe eines anderen Programmes ausgeführt wird. C/C++ wird zwar sicherlich als SourceCode weitergegeben, aber ich führe den Code an sich nicht aus. Ich übersetze ihn mit einem Compiler und führe das resultat aus. Während der Schritt bei einer Skriptsprache immer wieder gemacht wird, wenn auch automatisiert. Das sollte aber auch jetzt nicht unbedingt eine ISO Definiton werden die auch das kleinste Detail beachtet 😉 Das mit der Skriptsprache zu unterscheiden ist wahrlich nicht immer einfach da es wie gesagt immer sonderfälle gibt.

Python kann ich Offiziel auch als Bytecode weiter geben, und bei Perl5 kann ich es auch Innoffiziel. Perl5 kann ich auch als ELF Binary weitergeben, womit ich dann auf mein Zielsystem nichtmal eine installiertes perl benötige. Allerdings ist in dieser Binary nichts anderes als die Perl Bibliotheken gelinkt, von daher kann man auch hier wieder Fragen ob es wirklich in Maschienencode kompiliert wurde, weil ja letztendlich immer die PVM mitgelinkt ist, und weiterhin die PVM den Code ausführt.

Die Sache ist halt das man nicht immer alles bis in das kleinste Detail herunterbrechen sollte. Man muss halt auch mal eben etwas so sehen wie es ist, ohne gleich jedes Detail zu betrachten. Und man sollte sich mehr die unterschiede und nicht die Gemeinsamkeiten ansehen. Ich kann auch wie gesagt zu jeder Methode Funktion sagen, das sie sehr viel gemeinsam haben. Genauso wie ein Interpreter und eine VM vieles gemeinsam haben. Jedoch besitzen Sie unterschiede, und durch diese Unterschiede (egal wie gering sie sein mögen) werden sie ausgezeichnet, nicht durch Ihre Gemeinsamkeiten. Und ich denke man kann da Perl/Python/Ruby schon als Skriptsprache bezeichnen. Während ich sage das C/C++ keine ist. Wenn man es doch macht dann hat man alle Ebenen durchbrochen.

Ich kann auch wie gesagt hingehen und beim OSI Modell alles bis auf die erste Schicht herunterbrechen, und sagen das alles nur BITs sind, und das TCP,UDP,FTP,HTTP alles identisch ist. Wenn ich das bei den Sprachen mache, kommt letztendlich wohl das gleiche dabei heraus das Perl/Python/Ruby/Java ... alle identisch sind.

Und hier gibt es noch ein Zitat was Larry Wall zu dem Thema sagt. 😉
http://perldoc.perl.org/perlfaq1.html#Is-it-a-Perl-program-or-a-Perl-script%3f

Ok. Ich glaube wir koennen uns darauf einigen, dass eine Sprache lediglich ein abstraktes mathematisches Modell ist, nichts weiter. Und die Frage, ob eine Programmiersprache eine Skriptsprache ist, treffen wir anhand ueblicher, am weitesten verbreiteter Implementierungen. Ok so?

Apollon hat geschrieben:

Ok. Ich glaube wir koennen uns darauf einigen, dass eine Sprache lediglich ein abstraktes mathematisches Modell ist, nichts weiter. Und die Frage, ob eine Programmiersprache eine Skriptsprache ist, treffen wir anhand ueblicher, am weitesten verbreiteter Implementierungen. Ok so?

Klaro, damit war ich persönlich schon immer mit einverstanden gewesen. 😉

Chaoswind hat geschrieben:

Da ich momentan mit ISDN via Call-by-Call unterwegs bin, hab ich nicht die notwendige Anbindung um die Links zu Studien zu sammeln. Aber kannst dich mal auf planet.python.org(?) umsehen. Da tauchen alle Monate mal irgendwelche Entwickler auf welche für oder gegen Typisierung argumentieren und dann tauchen auch entsprechende Links auf. Die Performanceverbesserungen liegen da immer um die 5% im günstigsten Fall. Woran es liegt, schwer zu sagen, aber es ist wohl anzunehmen das die 30 Jahre Entwicklung seitdem sich streng Typisierte Sprachen durchgesetzt haben, ein bisschen mehr als plastischere Spiele hervorbrachten 😉

Sorry wenn das ein wenig harsch klingt, aber wenn jemand eine Behauptung aufstellt, hat er sie auf Nachfrage auch zu untermauern/beweisen. Ansonsten ist die Behauptung sinnloses Geschwätz und eine Diskussion darüber ebenso sinnlos.
Ich werde mit Sicherheit nicht die Zeit opfern, um diverse Studien aufzutreiben um diese Aussage von Dir zu relativieren. Es machte für mich den Anschein als würdest Du die Studien gut kennen, denn sonst hättest Du Dich nicht darauf bezogen, aber so wie es aussieht habe ich mich geirrt.

Generell ziehe ich für mich den Schluss, dass Du lieber über Beispiele diskutierst, als über die Sache ansich. Ich habe ja schon mehrfach geschrieben, dass ich das für einen Fehler halte, da jedes Beispiel ein Gegenbeispiel hat. Du musst ja nicht mit mir übereinstimmen, aber ein wenig mehr Fleisch hätte ich mir für die Diskussion schon gewünscht.

Die Diskussion, ob eine CPU entwickelt werden kann, die Sourcecode ausführen kann, finde ich geradezu klassisch für Deine Art Beispiele auseinandernehmen zu wollen und nicht die Aussage dahinter verstehen zu wollen: Natürlich ist es möglich, eine solche CPU zu entwickeln. Die Frage ist doch eher, was man mit einer solchen CPU überhaupt anfangen kann und ob der zu erwartende Nutzen überhaupt die zu erwartenden Kosten dafür rechtfertigen würden. Macht es also überhaupt Sinn? Ich sage jetzt einfach mal ganz salopp, dass eine solche CPU für 0,01% aller mit einer CPU möglichen Anwendungen Sinn machen würde. Ist das jetzt dadurch wahr, das ich es schrieb und auch eine Prozentzahl geliefert habe?

Ob sich vor 30 Jahren "streng typisierte" (was soll das wieder heissen? Meinst Du die mögliche Anzahl verschiedener Variablentypen oder den Zwang der Typisierung?) Sprachen durchgesetzt haben, weil sie - was sind? Was sagt dieser Satz denn aus? Haben sie sich überhaupt durchgesetzt? Mit welchen Kriterien beurteilst Du das "durchgesetzt haben"? Wo ist die Untermauerung dieser These? Warum sind denn seit ein paar Jahren Sprachen wie Perl/Python/Ruby so populär geworden bzw. im Falle von Ruby und PHP erst entstanden, wenn sich schon vor 30 Jahren streng typisierte Sprachen durchgesetzt haben? Warum wurde Mitte der Achtziger in vielen Firmen Clipper (auch typenlos) mit xBase-Unterbau für ERP-Systeme eingeführt, die teilweise heute noch im Einsatz sind und weiterentwickelt werden? Das sind wahrscheinlich alles Versuche einiger Unbelehrbarer.

EDIT: BTW. scheint auch der Grund warum "vor 30 Jahren" hauptsächlich typisierte Sprachen eingesetzt wurden an Dir vorbei gegangen zu sein. /EDIT

Sorry, aber Beiträge Anderer versuchst Du auseinander zu nehmen und bringst im Gegenzug ungenaue Worthülsen.

Man kann immer versuchen, alles so zu drehen das es zur derzeitigen Argumentation passt. Allerdings sollte man das auch belegen können.

Nicht falsch verstehen, ich sehe typenlose Sprachen nicht als "besser" oder "schlechter" als typisierte Sprachen an. Aber ob das letzte Wort hinsichtlich dem Durchsetzen einer der beiden Möglichkeiten schon gesprochen ist, bezweifle ich jetzt mal ganz frech.

Sid Burn hat geschrieben:

Es gibt immer ein "aber" und du kannst dir die widelsten Konstrukte überlegen. Wenn man das aber macht dann endet es in einer endlos weden Diskussion ohne Sinn.

Du kannst über die Sprache selber eigentlich überhaupt nicht festlegen ob es Interpretiert oder Kompiliert wird. Und letztendlich kannst du zu jeder Sprache auch einfach einen Interpreter oder Compiler entwickeln wenn du es möchtest. Da die Sprache wie gesagt nur Syntax Regeln sind.

Du kannst also weiterhin zu allem ein "aber" suchen, und die nächsten 10 jahre weiter diskutieren, oder einfach die häufigste Benutzung gelten lassen. Wie du dich entscheidest ist mir ziemlich egal, da es nichts an den aktuellen Umständen ändern wird.

Dem stimme ich vollkommen zu, genau wie den Sid Burns Beiträgen zu Perl und "Linux - alles eine Datei". Ebenso stimme ich Apollon zu, dessen Postings meiner Interpretation *g* nach aussagen, dass es eben mehr als nur schwarz und weiss gibt (bitte berichtigen, wenn falsch). Und user_unknown bei seinen Beiträgen mit der Java-CPU sowieso.
Aber was Du hier so an manchen Stellen geschrieben hast, ist meiner Meinung nach einfach fraglich. Auf Basis eines "Ich hab da mal gelesen" kann man nicht diskutieren, finde ich.

Sorry, aber sowas finde ich nicht einmal annähernd gut.

Durchsetzen muß man nicht so verstehen wie bei einem Tennismatch, wo sich einer von zweien am Ende durchsetzt, sondern kann man so verstehen, als 'erobert sich viele Anhänger und verpufft nicht als kurzfristiger Hype'.
C, C++, Java und andere typisierte Sprachen haben sich gewiß durchgesetzt - das heißt aber nicht, daß sich andere Konzepte nicht auch durchgesetzt hätten.

user unknown hat geschrieben:

Apollon hat geschrieben:

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

Ich habe nicht behauptet, es sei nicht möglich einen solchen Prozessor zu entwickeln.
Dieser Diskussionszweig begann damit, daß ich korrigierend behauptet habe, daß die CPUs, die Javacode direkt ausführen können, Java-Bytecode und nicht Sourcecode ausführen.

Und hab lediglich behauptet das ich diese CPUs nicht kenne, es aber nicht für unmöglich das sie nicht auch QUellcode direkt verarbeiten können. Danz unabhängig davon was diese realen CPUs wirklich können, da ich deren realen Faehigkeiten eben nicht kenne und erst recht nicht weiss was in irgendwelchen Laboren an Plaenen und Prototypen rumliegen.

BTW Werden diese Java-CPUs eigentlich irgendwo im Produktiven einsatz eingesetzt? Oder sind das nur Wunschvorstellungen von Sun-Managern?

user unknown hat geschrieben:

Es ist offenbar von diesen speziellen Java-CPUs die Rede, denen man aber auch beibringen kann, den Quellcode zu verarbeiten.
Das wirft meine Vorstellungen von CPUs ziemlich über den Haufen, aber da ich keine derartige CPU habe lasse ich mir gerne vorführen, wie man einer solchen CPU beibringt, Quellcode auszuführen. Das ist keine große Kunst.
Man lernt ja nie aus.

Dann korrigiere deine Vorstellungen von CPUs. Quellcode ist nur eine ansammlung von Bits. Ob es sinnvoll ist wenn eine CPU die aufgabe des Compilers mitübernimmt sei dahingestellt, aber es ist ohne weiteres möglich. So komplex ist ein Java-Compiler auch nicht, reine Fleissarbeit. Interessanter wird's bei den Optimierungen.

Apollon hat geschrieben:

Ich habe ja schon geschrieben, dass Woerter durchaus mehrdeutig sein koennen. Also nochmal fuer dich:
compiler [comp.] : der Übersetzer
interpreter [comp.] : der Übersetzer

🙄
Die übersetzungen wurden hier schon mehrmals genannt, auch vor deinem belanglosen Beitrag. Und sie lösen rein gar nichts. Und wie bereits erwaehnte ist Leo kein spezialisiertes Wörterbuch, d.h. primaer richtet sich obiges auf Menschliche Übersetzer, nicht Programme und ihre funktionen.

Apollon hat geschrieben:

Chaoswind hat geschrieben:

Apollon hat geschrieben:

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.

Und wir wissen ja wie unfehlbar und allwissend die ISO ist :>
SCNR

Hmm... Also an der Uni haben uns die Profs das genauso beigebracht. Aber offensichtlich liegen sie alle falsch und Du weisst es besser. Dann lass uns doch aus deinem reichen Wissensfundus schoepfen und klaer uns bitte auf. Wenigstens mich, da hier scheinbar jeder ausser mir es bereits weiss. Teile uns/mir die richtige Definition einer Programmiersprache mit. Moeglicherweise wird dann sogar die ISO ihren Fehler einsehen und deine Definition uebernehmen.

Ich hab nicht behauptet das die ISO (in diesem fall) falsch liegt, den ich hab die Definition (wie schon geschrieben) einfach nicht gelesen. Ich hab lediglich angemerkt das man sich nicht allzusehr auf das verlassen sollte, was die ISO definiert. Da kann man auch ziemlich auf die Schnauze fliegen, übrigens genauso wenn man blindlings seinen Professoren vertraut 😉

Apollon hat geschrieben:

Es ist auch keine grosse Kunst. Allerdings stehen der Arbeits- und Kostenaufwand in keiner Relation zum Nutzen einer solchen CPU. Daher wird das auch nicht gemacht. Als Forschungsprojekt wurde es jedoch durchgefuehrt. Das schrieb ich aber schon (Scheme-CPU).

Also laden direkt Quellcode und keinen vorkompilierten Code?

Sid Burn hat geschrieben:

Skriptsprachen zeichnen sich dadurch aus das sie weniger zwänge haben. Da use strict eine option ist, passt Perl ohne weiteres in diese definition. Um das nochmal verständlich zu machen: es geht nicht darum was eine Sprache erlaubt, sondern zu was einem eine Sprache zwingt.

Ne, dass ist Quatsch. Hast du noch so ein paar Sonderregeln damit du alles irgendwie zurecht biegen kannst? Und deine definition ist total wirsch.

Erstens ist das nicht meine Definition, sondern jene die bei der Skriptsprache]Wikipedia.[/wikipedia]
steht. Zweitens ist sie ziemlich verbreitet und sehr zutreffend. Drittens, wer im Glashaus sitzt...

Sid Burn hat geschrieben:

Ab welchen Grad von zwang und nicht zwang ist es den genau Skript- und wann nciht mehr Skriptsprache? Python zwingt mich meinen Code eingerückt zu Schreiben, C/C++ nicht. Da mich C/C++ zu weniger zwingt ist es jetzt eine Skriptsprache, und weil mich Python zu mehr zwingt ist es keine? Genau das ist total Sinnlos.

Oh bitte, was soll jetzt dieses Infantile getrolle? C hat KLammern, Python einrückungen und Ruby Begin/End. Marker zur Blockbildung haben die meisten Sprachen, die wird man nur schwerlich los.

Sid Burn hat geschrieben:

Genau mit dieser definition kann man überhaupt nichts festlegen.

Dafuer funktioniert sie aber extrem gut.

Zum deinem restlichen gesabbel sag ich einfach nichts mehr. Weder liest du was ich schreibe, noch strengst du dich auch nur im entferntesten an es zu verstehen. Diskussionen mit dir sind damit absolut sinnlos.

BTW noch etwas zum nachdenken: Funktionalle Sprachen werden auch Interpretiert, aber nicht Zeile für Zeile.

rincewind hat geschrieben:

Sorry wenn das ein wenig harsch klingt, aber wenn jemand eine Behauptung aufstellt, hat er sie auf Nachfrage auch zu untermauern/beweisen. Ansonsten ist die Behauptung sinnloses Geschwätz und eine Diskussion darüber ebenso sinnlos.

An und fuer sich richtig. Aber das aendert nicht meine momentanen Zugangsbeschraenkung. Du kannst auch gerne ein paar Wochen warten bis ich wieder DSL hab, oder es einfach glauben das Menschen existieren die dinge getestet haben deren Ergebnisse man auch nicht wirklich nachvollziehen kann 😉 Ansonsten wart das einfach nur eine belanglose nebenfrage in einer eher belanglosen diskussion.

rincewind hat geschrieben:

Generell ziehe ich für mich den Schluss, dass Du lieber über Beispiele diskutierst, als über die Sache ansich. Ich habe ja schon mehrfach geschrieben, dass ich das für einen Fehler halte, da jedes Beispiel ein Gegenbeispiel hat. Du musst ja nicht mit mir übereinstimmen, aber ein wenig mehr Fleisch hätte ich mir für die Diskussion schon gewünscht.

Ich diskutiere nicht über beispiele, ich untermale Diskussionen mit praktischen Bildern. Etwas allseits bekanntes ist nun mal leichter nachvollziehbar als eine abstrakte erklaerung. Allerdings, wenn man sich dann natuerlich am konkreten beispiel aufhaengt, statt versucht die erklaerung darin zu finden...

rincewind hat geschrieben:

Die Diskussion, ob eine CPU entwickelt werden kann, die Sourcecode ausführen kann, finde ich geradezu klassisch für Deine Art Beispiele auseinandernehmen zu wollen und nicht die Aussage dahinter verstehen zu wollen: Natürlich ist es möglich, eine solche CPU zu entwickeln. Die Frage ist doch eher, was man mit einer solchen CPU überhaupt anfangen kann und ob der zu erwartende

Ich hab nicht behauptet das es sinnvoll ist, nur das ich es für möglich halte das solche CPUs existieren. Liest hier eigentlich hier irgendjemand oder wird einfach nur blind geantwortet?

Abgesehen davon, solange niemand hier Java-CPUs entwickelt (oder etwas vergleichbares) sind Diskussionen über den nutzen solcher Features vollkommen Substanzlos.

rincewind hat geschrieben:

Ob sich vor 30 Jahren "streng typisierte" (was soll das wieder heissen? Meinst Du die mögliche Anzahl verschiedener Variablentypen oder den Zwang der Typisierung?) Sprachen durchgesetzt haben, weil sie - was sind? Was sagt dieser Satz denn aus? Haben sie sich überhaupt durchgesetzt?

Hm? Strenge Typisierung ist nun wirklich kein unbekannter Begriff. Es heisst einfach das eine verbindliche Typisierung besteht. Und vor 30 Jahren wurde C entwickelt, IIRC. C ist der prototyp einer Streng Typisierten Sprache und hat sich zweifelsohne am Markt durchgesetzt, inklusive nerviger nachfolger wie C++, Java, C#, Objective-C, etc. Daneben gibt es noch Ada und Pascal/Delphi, welche auch recht erfolgreich am Markt waren. Aber danach wird es reichlich dünn mit Sprachen. Dann kommen noch Skriptsprachen, uralte klöpper und sehr spezialisierter kram.

rincewind hat geschrieben:

Warum sind denn seit ein paar Jahren Sprachen wie Perl/Python/Ruby so populär geworden bzw. im Falle von Ruby und PHP erst entstanden, wenn sich schon vor 30 Jahren streng typisierte Sprachen durchgesetzt haben?

Ist dir schon der Gedanke gekommen das die dinge sich weiterentwickeln? Die letzten 20-30 Jahre des 20.Jhd. hat die IT-Welt sich hauptsaechlich mit Typisierten und Streng Typisierten Sprachen rumgeschlagen. Obendrein hauptsaechlich noch mit Kompilierten. Interpretierte und Un/Dynamischtypisierte Sprachen gab es früher nur wenige und kaum erfolgreiche, da einfach noch zu langsam. D.h. die Erfahrungen mit Dynamischen Sprachen werden jetzt erst langsam gemacht. Java existiert auch seit mittlerweile 15(?) Jahren, hat aber immer noch einen schlechten ruf was Geschwindigkeit anbelangt. Das klassische Bild Compiler=Schnell, Interpreter=Langsam steckt immer noch in vielen Köpfen, genauso wie Typisiert=Schnell, Untypisiert=Langsam. Wir hantieren heute mit Vorurteilen die auf Erfahrungen von vor 20-30 Jahren basieren. Lisp, Smalltalk, Basic, mit deren ersten Implementierungen argumentieren wir, wenn wir die Faehigkeiten moderner Dynamischer Sprachen betrachten.

Java-Prozessoren:
imsys: http://www.imsys.se/products/microprocessors.htm
ibm: http://www.theserverside.com/news/thread.tss?thread_id=24985
jop: http://www.jopdesign.com/
xilinx: http://www.xilinx.com/prs_rls/0134lavacore.htm
sun: http://bwrc.eecs.berkeley.edu/CIC/announce/1997/microjava.annc.html
usw.

Chaoswind hat geschrieben:

Dann korrigiere deine Vorstellungen von CPUs. Quellcode ist nur eine ansammlung von Bits. Ob es sinnvoll ist wenn eine CPU die aufgabe des Compilers mitübernimmt sei dahingestellt, aber es ist ohne weiteres möglich. So komplex ist ein Java-Compiler auch nicht, reine Fleissarbeit. Interessanter wird's bei den Optimierungen.

Also doch eine imaginäre CPU.

Ursprünglich hieß es, daß man diesen JavaCPUs beibringen könnte, Quellcode zu auszuführen.
Jetzt soll der Compiler in Hardware gebaut werden.
Ich dachte bislang, ein Compiler bringt den Quellcode in eine Form, die eine Maschine ausführen kann, und die Behauptung sei gewesen, daß die CPUs Quellcode direkt ausführen, also nicht compilieren.
Naja - das ist alles Kraut und Rüben geworden - sei es, weil Du ständig den Standpunkt änderst, sei es, weil Du Dich von Anfang an mißverständlich ausgedrückt hast.

Inzwischen folgen wohl nur noch hartgesottene Existenzen dem Thread - ich bin es leid alle kleinen Fehlinformationen zu korrigieren...
bye, bye

user unknown hat geschrieben:

Ich dachte bislang, ein Compiler bringt den Quellcode in eine Form, die eine Maschine ausführen kann,

D.h. nicht das sie ein zwang sind wenn man Quellcode ausführen will. Man kann sie nutzen, muss aber nicht.
Für deine fehlinterpretationen kann ich nun wirklich nichts.

Chaoswind hat geschrieben:

Sid Burn hat geschrieben:

Chaoswind hat geschrieben:

Skriptsprachen zeichnen sich dadurch aus das sie weniger zwänge haben. Da use strict eine option ist, passt Perl ohne weiteres in diese definition. Um das nochmal verständlich zu machen: es geht nicht darum was eine Sprache erlaubt, sondern zu was einem eine Sprache zwingt.

Ne, dass ist Quatsch. Hast du noch so ein paar Sonderregeln damit du alles irgendwie zurecht biegen kannst? Und deine definition ist total wirsch.

Erstens ist das nicht meine Definition, sondern jene die bei der Skriptsprache.
steht. Zweitens ist sie ziemlich verbreitet und sehr zutreffend. Drittens, wer im Glashaus sitzt...

Ich habe mir den Artikel durchgelesen, und im ganzen Artikel steht nirgendswo eine Definition von Skriptsprache. Und schon gar nicht steht dort irgendwo das eine Programmiersprache einem zu weniger Zwingen muss, damit es eine Skriptsprache wird. Zum anderen sagst du selber der ISO soll man nicht alles glauben, verlinkst aber wikipedia Artikel schon so, als wenn dort alles wahr wäre was dort drin steht. Und wenn ich den Artikel durchlese ist die einzige Definition zu Skriptsprache eher mehr identisch mit dem was ich sagte:
Wikipedia hat geschrieben:

Programme, die in Skriptsprachen geschrieben sind, werden auch Skripte genannt. Skripte werden fast ausschließlich in Form von Quelltextdateien ausgeliefert, um so ein einfaches Bearbeiten und Anpassen des Programms zu ermöglichen.

2) Weit verbreietet? Ich habe vor dir noch nie eine Definition gehört das man es dann mit einer Skriptsprache zu tun hat, wenn man zu weniger "gezwungen" wird. Bisher kenne ich als Argument nur das gequotete, und meine Aussage.

Chaoswind hat geschrieben:

sid burn hat geschrieben:

Ab welchen Grad von zwang und nicht zwang ist es den genau Skript- und wann nciht mehr Skriptsprache? Python zwingt mich meinen Code eingerückt zu Schreiben, C/C++ nicht. Da mich C/C++ zu weniger zwingt ist es jetzt eine Skriptsprache, und weil mich Python zu mehr zwingt ist es keine? Genau das ist total Sinnlos.

Oh bitte, was soll jetzt dieses Infantile getrolle? C hat KLammern, Python einrückungen und Ruby Begin/End. Marker zur Blockbildung haben die meisten Sprachen, die wird man nur schwerlich los.

Mit dem Text den ich schrieb wollte ich von dir Wissen welche Punkte den nun entscheidend sind, und welche Sachen genau "erzwungen" werden müssen, damit man es mit einer Skriptsprache zu tun hat. Den Text den ich schrieb sollte verdeutlichen das die Aussage an sich total lächerlich ist, und du so nicht einfach stehen lassen kannst. Zum anderen stellt sich überhaupt die Frage warum das "erzwungen" werden muss damit etwas nach deiner Meinung erstmal überhaupt gültig ist. Zu beiden gibst du keine Antwort.

Chaoswind hat geschrieben:

Sid Burn hat geschrieben:

Genau mit dieser definition kann man überhaupt nichts festlegen.

Dafuer funktioniert sie aber extrem gut.

Sehe ich nicht so. Meine Fragen konntest du jedenfalls nicht beantworten.

Chaoswind hat geschrieben:

Zum deinem restlichen gesabbel sag ich einfach nichts mehr.

So kann man natürlich auch einer Diskussion aus dem Weg gehen wenn einem die Argumente fehlen. 😉

BTW noch etwas zum nachdenken: Funktionalle Sprachen werden auch Interpretiert, aber nicht Zeile für Zeile.

Dann noch etwas zum nachdenken von mir.
Von der reinen Sprachpardigmen OOP, Prozedural etc. kann man nicht ableiten ob eine Sprache Interpretiert, Kompiliert oder was auch immer wird.

Chaoswind hat geschrieben:

Weder liest du was ich schreibe, noch strengst du dich auch nur im entferntesten an es zu verstehen. Diskussionen mit dir sind damit absolut sinnlos.

Gerade du willst mir sagen das du versuchst den "Sinn" hinter etwas zu verstehen, und es nicht nur Wort für Wort liest?
Wenn man sagt das ein Interpreter Zeile für Zeile einliest, dann bedeutet es das der Interpreter das Programm erst während der Ausführung "bearbeitet". Das bedeutet aber nicht das er wirklich Zeile für Zeile einliest und diese bearbeitet. Wenn ich einen Befehl auf zwei Zeilen aufsplitte, dann muss er natürlich auch zwei Zeilen einlesen damit er diesen bearbeiten kann.

Wenn du natürlich nur Wort für Wort liest und auch nicht anstrengest zu verstehen was es bedeutet, dann kann man natürlich auf die Idee kommen das wirklich eine Zeile eingelesen, und bearbeitet wird, und dann mit der nächsten Fortgefahren wird.