Aha die Pointer haben also überlebt, da kommt mir Gift und Galle hoch. Scheint mir nur ein weiterer C-Klon zu sein, ich sehe da keine großen Reformen. Ich würde mir eine hardwarenahe Sprache mit java-ähnlicher Syntax wünschen (was aber anscheinend ein Widerspruch in sich sein dürfte).
Scheint mir nur ein weiterer C-Klon zu sein, ich sehe da keine großen Reformen.
Naja, was sind "große Reformen"? Schon allein Support für Klassen und für Schleifenkonstrukte mit Typinferenz für Laufvariable deuten auf alles andere als einen C-Klon hin. Erweiterung ja vielleicht, ist ja auch nicht unbedingt schlecht. Wie auch ein "Klon", der einige der nervigeren Probleme beseitigt, nicht unbedingt schlecht wäre.
Ich würde mir eine hardwarenahe Sprache mit java-ähnlicher Syntax wünschen (was aber anscheinend ein Widerspruch in sich sein dürfte).
Was meinst du mit Syntax? Für "hardwarenahe" Programmierung ist z.B. die von dir blöd gefundene Unterscheidung zwischen Stack- und Heapobjekten (Zeiger/Referenzen vs. nicht-Zeiger/Referenzen) wichtig.
Für "hardwarenahe" Programmierung ist z.B. die von dir blöd gefundene Unterscheidung zwischen Stack- und Heapobjekten (Zeiger/Referenzen vs. nicht-Zeiger/Referenzen) wichtig.
Ich gebe zu, mir fehlt da der genaue Einblick, aber wozu dazwischen unterscheiden?
Aha die Pointer haben also überlebt, da kommt mir Gift und Galle hoch.
Was ist an Pointern Schlechtes?
Zitat von klausiIch gebe zu, mir fehlt da der genaue Einblick, aber wozu dazwischen unterscheiden?
"Hardwarenahe Programmierung" ist ein schwammiger Begriff, aber er kann zum Beispiel bedeuten, daß man an ganz konkrete fixe Speicheradressen zugreifen muß, inklusive Adressarithmetik (daher Pointer, siehe gleich), und daß die Befehle und Datentypen der Hochsprache irgendwie möglichst direkt auf die zugrundeliegende Maschine abgebildet werden (daher auch primitive Datentypen, die nicht über Pointer oder Referenzen referenziert werden).
Jetzt kann man in C-Syntax sowas schreiben (Skizze):
#define MEIN_MEMORY_MAPPED_INPUTREGISTER ((unsigned char *) 0x283A82FE) /* siehe Prozessor-Doku */
#define MEIN_MEMORY_MAPPED_OUTPUTREGISTER ((unsigned int *) 0x8D92A9CA)
#define MEINE_DINGSBUMSTABELLE ((unsigned int *) 0x0000ABCD)
unsigned char das_will_ich_wissen = *MEIN_MEMORY_MAPPED_INPUTREGISTER;
unsigned int *da_will_ich_hinschreiben;
*da_will_ich_hinschreiben = das_will_ich_wissen + 3;
MEINE_DINGSBUMSTABELLE[42] = 23;
Um das so relativ angenehm ausdrücken zu können, braucht man Pointer.
In Java-ähnlicher Syntax würde das dann vielleicht so aussehen:
Address input = new Address(0x283A82FE);
Address output = new Address(0x8D92A9CA);
Address tabelle = new Address(0x0000ABCD);
char sagsMir = input.readChar();
output.writeInt(sagsMir + 3);
tabelle.writeIntWithOffset(23, 42);
Ist natürlich möglich, das so zu formulieren; stellt sich die Frage, ob es Sinn hat, so eine Sprache zu konstruieren, nur damit der Programmierer mehr tippen kann als in C. Wenn Address in diesem Beispiel eine echte Klasse ist, hat man Konstruktor- und Methodenaufrufe, die das ganze um Größenordnungen langsamer machen als die C-Variante; wenn es keine echte Klasse ist, hat man eine Sprache, in der alles wie eine Klasse aussieht, einiges aber keine Klasse ist. Auch nicht wahnsinnig sauber.
Was ist an Pointern Schlechtes?
http://de.wikipedia.org/wiki/Zeiger_%2…le_und_Gefahren
Für mich persönlich ist es einfach komplett unverständlich. Ich will mich beim Programmieren nicht dauernd mit Nachdenken über den richtigen Variablenzugriff abgeben. Einheitliche Referenzen immer und überall sind z.B. in Java sehr komfortabel.
Da Referenzen auch nur Zeiger ohne Sterndeln sind, treffen fast alle diese Punkte auch auf Referenzen zu.
Für mich persönlich ist es einfach komplett unverständlich. Ich will mich beim Programmieren nicht dauernd mit Nachdenken über den richtigen Variablenzugriff abgeben.
Fair enough, manchmal steht die elegante Formulierung der Lösung des Problems im Vordergrund; manchmal gehts um jedes letzte Stücki Performance bzw. um direkte Speicherzugriffe (wenn man Embedded Systems oder Hardwaretreiber oder Betriebssysteme schreibt), dann muß man wohl oder übel in einem konkreteren Maschinenmodell denken, inklusive Unterscheidung zwischen Stack und Heap (automatischen bzw. dynamischen Variablen).
Außerdem gibts die begründete Meinung, daß ein Programmierer (wir sind ja bitte nicht irgendwer, sondern theoretisch hochbezahlte höchstqualifizierte Denker, auch wenn sich viele für 08/15-PHP-SQL-Zeug hergeben) gefälligst wissen soll, was er tut; über Details wie Variablenzugriffe nachdenken gehört dazu. Mußt du auch in Java machen, jedesmal wenn du eine Zuweisung schreibst; kopierst du jetzt eine Referenz oder doch Daten, und ist das das, was du wirklich willst? Du könntest jetzt natürlich sagen ja, darüber muß man zwar eigentlich nachdenken, aber irgendwann hat man es im Blut und man schreibt automatisch die richtige Variante -- bingo, wenn es bei Referenzen so ist, ist es bei Zeigern auch so.
Einheitliche Referenzen immer und überall sind z.B. in Java sehr komfortabel.
Einheitliche Referenzen immer und überall sind in Smalltalk komfortabel und dementsprechend langsam; in Java sind einheitliche Referenzen nicht vorhanden. In anderen Worten: Erklär einem Anfänger, der sich zum Glück nicht mit Zeigern plagen muß, den Unterschied zwischen int und Integer.
Fair enough, manchmal steht die elegante Formulierung der Lösung des Problems im Vordergrund; manchmal gehts um jedes letzte Stücki Performance bzw. um direkte Speicherzugriffe (wenn man Embedded Systems oder Hardwaretreiber oder Betriebssysteme schreibt), dann muß man wohl oder übel in einem konkreteren Maschinenmodell denken, inklusive Unterscheidung zwischen Stack und Heap (automatischen bzw. dynamischen Variablen).
Ja, ich denke auch, dass C nur wegen seinen Performancefähigkeiten überlebt hat. Warum nicht ordentliche Maschinenmodelle konstruieren für ordentliche Programmiersprachen?
Mir liegt Java deutlich mehr im Blut als C (vor allem dadurch bedingt, dass ich viel mehr in Java programmiere), in C gibt es einfach zu viele Operatoren für mein kleines Hirn (brauche ich jetzt "*" oder "&" oder "->" oder was anderes oder doch gar nix?). In Java gibts nur einen freundlichen "." 
Erklär einem Anfänger, der sich zum Glück nicht mit Zeigern plagen muß, den Unterschied zwischen int und Integer.
OK, das war klar, dass du mit den primitiven Datentypen konterst
Obwohl die 2 genannten durch Autoboxing seit Java 1.5 ja auch ein bißchen weiter zusammengewachsen sind.
... D verspricht hohe Performance, sparsamen Umgang mit Ressourcen sowie gute Les- und Wartbarkeit durch leicht verständlichen und zugleich kompakten Code.D verspricht hohe Performance, sparsamen Umgang mit Ressourcen sowie gute Les- und Wartbarkeit durch leicht verständlichen und zugleich kompakten Code. ...
Das ist meiner Meinung nach ein krasser Wiederspruch, man kann eine Sprache nicht zugleich fuer den Compiler und den Programmierer optimieren.
"Les- und Wartbarkeit, leicht verstaendlicher und kompakter Code", alle diese Dinge erhaelt man doch durch einen hohen Grad von Abstraktion. Fuer Performance aber braucht man die Kontrolle ueber Details.
Ich glaube was wir hier haben ist (mal wieder) der Versuch einer eierlegenden Wollmilchsau, und weil D von der Syntax ungefaehr so aussieht wie die in der Wirtschaft gerade populaeren Sprachen C++,Java und C#, gibt es sogar Hoffnung auf Erfolg. Sowohl akademisch als auch wirtschaftlich gesehen find ich die Sprache aber nicht besonders interessant.
D hat ein halbherziges, sehr kompliziertes objektorientiertes Design. Es hat eine aufgeblaehte und wenig intuitive Syntax und kommt von der Performance her sicher nicht an C heran. Wenn man seine Programme in einer moeglichst abstrakten Sprache entwicklelt, und fuer performancekritische Probleme eine zweite, maschinennahe Sprache einsetzt, ist man der Wollmilchsau D doch wohl immer einen Schritt voraus?
Was wir wirklich brauchen koennten waehre eine neue Version von Smalltalk, die besser mit bestehenden Systemen zusammenarbeitet. Oh, aber die gibt es ja schon laengst. Nennt sich Ruby.
Ja, ich denke auch, dass C nur wegen seinen Performancefähigkeiten überlebt hat. Warum nicht ordentliche Maschinenmodelle konstruieren für ordentliche Programmiersprachen?
Wenn du einen Vorschlag hast, Objekte in der Hardware anders als durch Zeiger darzustellen, bitte rück raus damit, du könntest einiges damit revolutionieren.
Außerdem _ist_ C eine ordentliche Programmiersprache, wenn man sie für Dinge verwendet für die sie geeignet ist, und hat den großen Vorteil, dass man den Speicherver- und gebrauch gut unter Kontrolle hat. Btw. sind Zeiger wirklich so schwer zu verstehen? Ich mein es ist genau _ein_ Prinzip, * in die eine Richtung, & in die andere, fertig. Alleine die Sichtbarkeitsregeln in Java sind wesentlich komplexer.
Dafuer dass, diese Sprache jetzt "Version 1.0" erreicht, ist sie ja schon recht weit oben im TIOBE-Index.
Wenn du einen Vorschlag hast, Objekte in der Hardware anders als durch Zeiger darzustellen, bitte rück raus damit, du könntest einiges damit revolutionieren.
Naja, im Endeffekt tut doch Java genau das. Eine Grundregel von Java ist, dass man nicht auf Objekte zugreifen kann, wenn man keine Referenz darauf hat, auch wenn das ganze im gleichen Adressraum (gleichen JVM) läuft (siehe Applets, die dürfen sich nicht gegenseitig beeinflussen können). Da darf in Java selbst auf Bytecode-Niveau keine Speicheradresse verwendet werden. Dass die JVM noch nie direkt in Hardware implementiert wurde ist hier recht nebensächlich, schließlich & endlich wird der x86er Bytecode auch nicht mehr in Hardware implementiert seit einer Weile.
Wie das jetzt genau auf dem JVM-Assembler-Niveau funktioniert weiß ich auch nicht, aber das ist definitiv keine revolutionäre Idee mehr.
Was wir wirklich brauchen koennten waehre eine neue Version von Smalltalk, die besser mit bestehenden Systemen zusammenarbeitet. Oh, aber die gibt es ja schon laengst. Nennt sich Ruby.
Da habe ich wiederum zu wenig Hirn und baue durch die dynamische Typisierung hinterhältige Fehler in meinen Code ein.
Wenn du einen Vorschlag hast, Objekte in der Hardware anders als durch Zeiger darzustellen, bitte rück raus damit, du könntest einiges damit revolutionieren.
Macht ja nix, wenn die Objekte mit Zeigern in der Hardware realisiert werden, solange die darauf aufsetzende Programmiersprache das vor mir verbirgt.
Was wir wirklich brauchen koennten waehre eine neue Version von Smalltalk, die besser mit bestehenden Systemen zusammenarbeitet. Oh, aber die gibt es ja schon laengst. Nennt sich Ruby.
Ruby wäre echt meine Traumprogrammiersprache, wenn es einen guten Compiler dafür gäbe :wein:
Da habe ich wiederum zu wenig Hirn und baue durch die dynamische Typisierung hinterhältige Fehler in meinen Code ein.
Ich gebe Dir recht, dass sich bei dynamischer Typisierung Fehler einschleichen koennen. Auf der anderen Seite fuehrt statische Typisierung aber zu deutlich mehr Code, und die Menge des Codes haengt sehr stark mit der Anzahl der produzierten Fehler zusammen.
Am Ende hat also beides seine Schwaechen. Aber gegen Typfehler kann ich als Programmierer zumindest was machen (naemlich Unit Tests die man ja eigentlich sowieso immer machen sollte). Viel Code bleibt aber immer viel Code.
Ruby wäre echt meine Traumprogrammiersprache, wenn es einen guten Compiler dafür gäbe :wein:
Dazu eine Randbemerkung:
JRuby ist ein stabiles und sehr aktives Projekt. Die Entwickler wurden vor ein paar Monaten von Sun eingestellt, damit sie Fulltime an dem Projekt weiterarbeiten koennen. D.h. die Zukunft ist auch relativ sicher. Und unter den Programmierern sind richtig clevere Hacker wie Ola Bini. Ich hab mir schon ueberlegt, ob ich nicht ganz von C-Ruby auf JRuby umsteigen soll.
Was C-Ruby selbst betrifft, ist YARV seit Montag offiziell im Ruby 1.9.1 trunk. Und um den japanischen Developer zu zitieren "YARV make fast all Ruby Program by 50 times" (quelle).
Das Zitat erinnert mich uebrigens daran was ich mir von Ruby wuenschen wuerde: Naemlich das die vielen Japanischen Entwickler mal richtig Englisch lernen. 
Dafuer dass, diese Sprache jetzt "Version 1.0" erreicht, ist sie ja schon recht weit oben im TIOBE-Index.
Ich glaube der Tiobe index hat bei einigen Sprachen sehr grosse Probleme, halbwegs brauchbare Statistiken zu liefern. Eine webseite mit einem Text wie
"Here is my code, written in the Java programming: d = new Distance();"
wuerde z.B. schon als Stimme fuer die Sprache D zaehlen.
[ Update: Bin mir gar nicht mehr so sicher ob das stimmt: "The search query that is used is +"<language> programming". Wenn die Anfuehrungsstriche in der Query sind ist das Beispiel oben nicht mehr korrekt ]
Natuerlich kann man nicht erwarten, dass so eine Statistik wie die von Tiobe genau ist, aber bei manchen Sprachen ist das Ergebnis sicher schlechter als bei anderen.
Ein anderes Problem ist z.B. VB: Visual Basic und Visual Basic.NET sind zwei voellig unterschiedliche Sprachen, aber ueber eine Suchanfrage kannst Du die kaum sinnvoll auseinanderhalten. Also musste TIOBE sie einfach wie eine einzelne Programmiersprache behandeln.
Dazu eine Randbemerkung:
JRuby ist ein stabiles und sehr aktives Projekt.
JRuby ist trotzdem immer noch ein Interpreter! Wenn JRuby Bytecode produzieren würde, wär das ja wirklich eine tolle Option (speziell mit der einfachen Integration mit Java).
Selbst als Interpreter ist JRuby sicherlich sehr interessant.
Die Entwickler wurden vor ein paar Monaten von Sun eingestellt
Besser die Entwickler als die Entwicklung
Das Zitat erinnert mich uebrigens daran was ich mir von Ruby wuenschen wuerde: Naemlich das die vielen Japanischen Entwickler mal richtig Englisch lernen.
Naja, oder der echte Ruby-Fan lernt Japanisch それなら簡単だ。
Da darf in Java selbst auf Bytecode-Niveau keine Speicheradresse verwendet werden. Dass die JVM noch nie direkt in Hardware implementiert wurde ist hier recht nebensächlich, schließlich & endlich wird der x86er Bytecode auch nicht mehr in Hardware implementiert seit einer Weile.
Ja, sie darf nicht so verwendet werden, weil es durch Typisierung verboten wird, die Darstellung des Werts selbst wäre die gleiche (cf. Ausgaben wie "[I@126b249'). Es wird hier konsequent zwischen Adressen und Zahlen unterschieden (der 68k hat auch eigene Adress- und Datenregister), ohne diese Unterschiedung wäre die JVM aber genauso effizient oder effizienter. Interessanter wäre etwas, was nicht bloß durch Einschränkung der Möglichkeiten entsteht.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!