Wie ist eure Meinung zur Programmiersprache D?

[FeuerKlaus]

Okay, die Sprache wird im produktiven Umfeld so gut wie gar nicht eingesetzt und Firmen die dieser Sprache den Rücken stärken gibt's außer Digital Mars (den Erfindern der Sprache) eigentlich keine.

Allerdings spricht hier ja nichts dagegen, mal die Sprache von ihren Sprachkonzepten zu beurteilen und dann gegenüber den bestehenden Sprachen wie Java, C, C++, C# usw. einzuordnen.

Also, was haltet ihr von der Programmiersprache D?
Könntet ihr euch vorstellen, sie für ein Projekt mal einzusetzen und falls ja, was müßte dazu dann geschehen?

 

[FeuerKlaus]

Zwischen D Vers. 1.0 und D Vers. 2.0 gab es einige Änderungen.
Bezüglich dem Threadthema beziehen wir uns hier daher auf D Version 2.0.

 

[Paddelpirat]

Also, was haltet ihr von der Programmiersprache D?
Könntet ihr euch vorstellen, sie für ein Projekt mal einzusetzen und falls ja, was müßte dazu dann geschehen?

Hatte D mal angesehen, als es gerade raus kam, hab es dann aber nicht mehr weiter verfolgt. Mir gab es damals einfach zu wenig Unterschiede zu anderen Sprachen (Java und C++). Außerdem wurde ständig auf Code verwiesen, der dann doch wieder nur in C++ geschrieben war. Der Übergang war also fließend, aber wieso dann nicht gleich alles in C++ machen?

Der größte Kritikpunkt ist aber wohl das was du gleich im ersten Satz geschrieben hast. Es benutzt kaum jemand D.

 

[MrWhite]

Es gab mal einen guten Thread auf Programmers dazu:

programming languages - What does C++ do better than D? - Programmers - Stack Exchange

Lass dich vom Titel nicht berirren, da sind ziemlich gute Vergleiche unter den Antworten mit dabei.

 

[Tellerschauer]

Es gab mal einen guten Thread auf Programmers dazu:

programming languages - What does C++ do better than D? - Programmers - Stack Exchange

Lass dich vom Titel nicht berirren, da sind ziemlich gute Vergleiche unter den Antworten mit dabei.

Danke für den Link.

 

[Landei]

D hat viele interessante funktionale Features, und die generelle Syntax ist einfacher und verständlicher als C++. Wenn ich eine systemnahe Sprache benötigen würde, würde ich es mit D probieren.

 

[DvsJava]

Wie schneidet denn D ab, wenn man es mit Java vergleicht?


Hier scheinen ja insbesondere die Compiler bezüglich D noch recht am Anfang zu sein, während der Java Compiler und die JIT schon hochoptimiert sind.

Durch den Garbage Collector dürfte es auch vom programmieren her näher an Java sein.


Was von beidem erzeugt den schnelleren Code, insbesondere wenn man bei D auf den GC nicht verzichten möchte?

 

[Paddelpirat]

Das mit dem schnelleren Code ist so ne Sache. Du kannst in allen (hier genannten) Sprachen schnellen, aber auch langsamen Code fabrizieren. Man muss halt wissen, was man tut. Ansonsten, wieso willst du D benutzen? Was für Vorteile siehst du darin?

 

[Spacerat]

Ich würde an dieser Stelle mal die Frage stellen, ob man plattformabhängige Sprachen überhaupt irgendwie mit plattformunabhängigen vergleichen sollte, sofern das überhaupt möglich ist - ich denke mal nicht. Faktisch kann man nun mal mit den plattformabhängigen Sprachen mehr Einfluss auf die Plattform selbst nehmen und hat dort deswegen schon mal nicht unbedingt mehr aber eine ganze Reihe anderer Möglichkeiten. Faktisch könnte man z.B. in Assembler oder in jeder anderen plattformabhängigen Programmiersprache auch sogar VirtualMaschines entwickeln, die eigenen oder aber auch fremden Code in Bytecode übersetzen um ihn bei Bedarf plattformunabhängig ausführen zu lassen, siehe DotNet (Mono). Und wenn sich so etwas erstmal durchsetzt, dann kann man auch z.B. Java mit D vergleichen.

 

[Plattformunabh]

C, C++, D, Ada usw. sind alles plattformunabhängige Sprachen.


Du meinst wohl eher plattformunabhängig auf Binärebene.

 

[Spacerat]

Egal wo kompiliert, trotzdem überall lauffähig - das ist plattformunabhängig. Dass eine Programmiersprache selbst (ausser vllt. Assembler) überall gleichermassen verwendet werden kann, ist doch wohl klar. Dass aber z.B. Java-Programme auch auf anderen Platformen laufen können, für die es eine Standard-Laufzeitumgebung gibt, anscheinend nicht. Kurz: Bei Plattformunabhängigkeit geht es nur um die Produkte.

 

[KuhTee]

Dass aber z.B. Java-Programme auch auf anderen Platformen laufen können, für die es eine Standard-Laufzeitumgebung gibt, anscheinend nicht.

In dem Fall ist die Laufzeitumgebung die Plattform

Die Plattformunabhängkeit sollte man nicht anhand von Sourcecode oder Binärcode festmachen.

 

[Spacerat]

In dem Fall ist die Laufzeitumgebung die Plattform

Die Plattformunabhängkeit sollte man nicht anhand von Sourcecode oder Binärcode festmachen.

:lol: Demnach wäre also alles plattformunabhängig? Nein, Kollegen, soweit ist es noch nicht. Mit den korrekten Laufzeitumgebungen könnte man nämlich alles irgendwo, irgendwie laufen lassen, z.B. Windowsprogramme direkt unter Linux oder gar Amigaprogramme unter Windows und ich rede hier keineswegs von irgendwelchen Emulatoren. Die Frage, nach dem, was man sollte stellt sich einfach nicht. Plattformunabhängigkeit ist die Wiederverwendbarkeit von Kompilaten auf verschiedensten Plattformen und nicht die Tatsache, dass sich für xbeliebige Sprachen Kompiler und Linker auf jeder Plattform finden lassen. Ein für Linux kompiliertes C++-Programm läuft halt nicht unter Windows ohne Hilfsmittel. Und eine Plattform zeichnet sich immer noch per Betriebssystem und Hardware aus und das unabhängig davon, welche Emulatoren oder virtuelle Maschinen darauf laufen und für C++ oder D gibt es afaik noch keine VM.
Aber BTW.: Ich finde, Plattformunabhängigkeit ist hier mehr oder minder Offtopic.

 

[KuhTee]

:lol: Demnach wäre also alles plattformunabhängig?

Nein. Ein C++ Programm (Sourcecode), welches WinAPI Funktionen nutzt ist nicht plattformunabhängig. Auch ein Java Programm (Kompiliert), welches Windows DLL nutzt, ist nicht plattformunabhängig. Man sieht also, man kann es nicht an Source/Binary festmachen.

Mit den korrekten Laufzeitumgebungen könnte man nämlich alles irgendwo, irgendwie laufen lassen, z.B. Windowsprogramme direkt unter Linux oder gar Amigaprogramme unter Windows

Es geht bei Plattformunabhängkeit auch nicht darum, sich zu verrenken, sondern etwas mit Bordmitteln zum Laufen zu bekommen. Und da zB ein Linux per Default immer einen GCC installiert hat, bekomme ich ein unter Windows programmiertes plattformunabhängiges C++ Programm unter Linux wahrscheinlich mit Bordmitteln zum Laufen, ein Java Programm aber nicht. Noch interessanter wird es natürlich für Plattformen, auf denen ich einen GCC habe, aber kein Java.

Ein für Linux kompiliertes C++-Programm läuft halt nicht unter Windows ohne Hilfsmittel.

Ein Java Programm läuft NIRGENDS ohne Hilfsmittel

und für C++ oder D gibt es afaik noch keine VM.

Doch, gibt es:
Low Level Virtual Machine ? Wikipedia
Aber auch die schützt dich nicht davor, plattformabhängige Programme zu schreiben

 

[Tobse]

Um wieder zum Them zu kommen:
Ich persönlich mag D, auch weil es einen einfacheren Syntax hat, Garbage Collection etc... Allerdings passiert es mir beim lernen von D alle 3 Zeilen, dass ich einen Fehler mache den der Compiler nich checkt und der Linker danns große kotzen kriegt. Und die Fehlermeldungen vom Linker haben mit dem Code absolut nichts zu tun und sind noch unaufschlussreicher als eine Zeilenangabe. Deshalb hat D für mich keine Zukunft solange der Compiler noch Müll ist. Daher war bei mir dann nach 20 min rmprobieren beim Thema D ein [X] angesagt.

 

[C_p_unabhäng]

:lol: Demnach wäre also alles plattformunabhängig?

Fast alle Hochsprachen für die es überall die entsprechenden Sprachstandardbibliotheken gibt.
Daher ja.
Eine Hochsprache wird erst plattformabhängig, wenn man auf Libs oder Kernelfunktionen ugreift, die plattformspezifisch sind.

Lediglich Assembler ist nicht plattformunabhängig.


Und ja, C, C++ usw. sind alles plattformunabhängige Sprachen auf Quellcodeebene und das ist der Bereich, wo die Sprache noch die Sprache ist.

Auf Binärcodeebene würde ich nicht mehr von einem Programm einer bestimmten Programmiersprache sprechen, sondern von einem Programm für eine bestimmte Plattform, ob Maschinencode oder VM ist da nebensächlich.



[/QUOTE]
Mit den korrekten Laufzeitumgebungen könnte man nämlich alles irgendwo, irgendwie laufen lassen, z.B. Windowsprogramme direkt unter Linux oder gar Amigaprogramme unter Windows
[/QUOTE]

Ein Programm das für Windows geschrieben wurde und eines, daß für den Amiga geschrieben wurde, sind beides Programme, die auch für komplett unterschiedliche CPU Architekturen geschrieben wurden. Insofern ist dein Vergleich absurd.

Plattformunabhängigkeit ist die Wiederverwendbarkeit von Kompilaten auf verschiedensten Plattformen

Nein, Plattformunabhängigkeit ist auch die Wiederverwendbarkeit von Quellcode auf verschiedenen Plattformen.
Nur einmal neu Compilieren und dann läuft es.

Das geht auch mit C, C++ usw. sofern man sich an Crossplattformbibliotheken hält, die Sprache selbst ist plattformunabhängig.

 

[C_p_unabhäng]

Um wieder zum Them zu kommen:
Ich persönlich mag D, auch weil es einen einfacheren Syntax hat, Garbage Collection etc... Allerdings passiert es mir beim lernen von D alle 3 Zeilen, dass ich einen Fehler mache den der Compiler nich checkt und der Linker danns große kotzen kriegt. Und die Fehlermeldungen vom Linker haben mit dem Code absolut nichts zu tun und sind noch unaufschlussreicher als eine Zeilenangabe. Deshalb hat D für mich keine Zukunft solange der Compiler noch Müll ist. Daher war bei mir dann nach 20 min rmprobieren beim Thema D ein [X] angesagt.

Welchen D Compiler benutzt du?

Es gibt ja inzwischen drei D Compiler.

Einmal den von Digital Mars, denn den für LLVM und noch GDC.

 

[Tobse]

Den 2.0 von DigitalMars, weil der für Windows und Linux verfügbar ist. Nach meinen Recherchen GDC aber nur fpr Linux, wmoti wir wieder bei dem anderen Thema wären.

 

[Spacerat]

Lediglich Assembler ist nicht plattformunabhängig.

Wieso nicht? Es ist doch eine Sprache? Zwar Prozessor spezifisch aber immerhin eine Sprache...

Ein Programm das für Windows geschrieben wurde und eines, daß für den Amiga geschrieben wurde, sind beides Programme, die auch für komplett unterschiedliche CPU Architekturen geschrieben wurden. Insofern ist dein Vergleich absurd.

...nur damit meine Aussage at absurdum gelegt werden kann, ist der Unterschied bei Plattformen plötzlich nur auf die Prozessorarchitektur begrenzt? Das ist absurd, denn es gibt Prozessoremulatoren ohne Ende. Aber ja, natürlich war meine Aussage absurd. Aber irgendwie bekommt man halt alles irgendwo zum Laufen - "Wieviel' Sprachen sprechen sie? Ich spreche nur eine..." usw.
Deswegen:

Plattformunabhängigkeit ist auch die Wiederverwendbarkeit von Quellcode auf verschiedenen Plattformen.
Nur einmal neu Compilieren und dann läuft es.

Das ist und bleibt schlicht Falsch. Plattformunabhängig ist's erst, wenn das Neukompilieren ausfällt und das gibt es nur bei Just-In-Time-Technologien wie z.B. Java oder C# mit anderen Worten Bytecode.

 

[Landei]

Wenn ich in C schon beim Datentyp int nicht weiß, wie groß der genau ist, ist mein C-Programm nicht plattformunabhängig, weil das gleiche Programm auf unterschiedlichen Computern unterschiedliche Ergebnisse liefert, ohne plattformspezifisch (also mittels nativer Bibliotheken u.s.w.) programmiert worden zu sein - eine einfache Addition kann schon einen Unterschied machen. Zu sagen C wäre plattformunabhängig ist wie zu sagen Schuhe sind größenunabhängig, weil man ja notfalls die Zehen abschneiden kann.

 

[C_p_unabhäng]

Wieso nicht? Es ist doch eine Sprache? Zwar Prozessor spezifisch aber immerhin eine Sprache...

Hast du überhaupt schonmal in Assembler progammiert?
Die Sprache ist schon allein deswegen nicht plattformunabhängig, weil der Assemblercode, den man damit erstellt, an den Prozessor gebunden ist.



Das ist der große Unterschied. Es sind ja nicht nur die einzelnen Befehlsbezeichnungen, sondern auch die Registernamen, die Byte Order, die Befehls- und Adressgröße usw. und die Art und weise wie man das ganze zu etwas größerem verwebt. Das ist bei Assembler immer plattformspezifisch.

Bei C, C++ usw. Code muß das so aber nicht sein.
Bei C kannst du dich z.B. strikt an den C Standard und die Standardlib halten und der Code wird überall compilierbar sein, deswegen ist C eine plattformunabhängige Sprache auf Quellcodeebene.

Jede While Schleife oder printf Ausgabe in C wird überall compilierbar sein, solange die Zielplattform den C Standard einhält und die Standardlib anbietet.
Selbst die Größen Ints, Double usw. kriegt man hin, wenn man die limits.h in seinem Code berücksichtigt und entsprechend programmiert.

Bei Assembler ist jede While Schleife schon so CPU Architektur spezifisch, daß sie nur auf einer Architektur funktioniert.
Zu meiner ersten Frage in diesem Posting denke ich nämlich nicht, daß du noch nicht in Assembler programmiert hast, denn sonst würdest du bzw. müßtest du dies wissen.

Das ist absurd, denn es gibt Prozessoremulatoren ohne Ende.

Wir sprechen von nativer Codeausführung und sicherlich nicht von Emulationen auf einer komplett anderen Hardware.

Das ist und bleibt schlicht Falsch. Plattformunabhängig ist's erst, wenn das Neukompilieren ausfällt und das gibt es nur bei Just-In-Time-Technologien wie z.B. Java oder C# mit anderen Worten Bytecode.

Dann benuztt doch mal in einer Pfadangabe in Java nen Backslash anstatt nen einfachen Slash und schon wirft dein Bytecode eine Exception unter Linux und läßt sich AFAIK auch nicht compilieren.

Ach was streite ich mit dir hier eigentlich herum, der noch nicht in Assembler programmiert hat.
Die Plattformunabhängigkeit von C, C++ usw. auf Quellcodeebene ist überall so anerkannt und genau das machen sich Tausende von z.B. Open Source Software Entwicklern zu nutze.
Für die Definition der Plattformunabhängigkeit kannst du ja auch einfach mal die Wikipedia zur Rate ziehen, auch da steht das drin.

Plattformunabhängigkeit ? Wikipedia

 

[C_p_unabhäng]

Bei Assembler ist jede While Schleife schon so CPU Architektur spezifisch,

Damit wir uns nicht falsch verstehen:
Ich meine damit die Implementierung einer While Schleife in Assembler.

While gibt's als Schlüsselwort oder Teil der Sprache in Assembler ja nicht, sondern wird mit den entsprechenden plattformspezifischen Assembleransweisungen implementiert.

 

[C_p_unabhäng]

Wenn ich in C schon beim Datentyp int nicht weiß, wie groß der genau ist, ist mein C-Programm nicht plattformunabhängig,

Dafür gibt's die limits.h und C Programmierer berücksichtigen das bei der Programmierung, wenn sie plattformunabhängigen Code erzeugen wollen.

Insofern ist das kein Argument, sondern es zeigt eher, daß du nicht viel Erfahrung in C hast.

 

[Spacerat]

Dann benuztt doch mal in einer Pfadangabe in Java nen Backslash anstatt nen einfachen Slash und schon wirft dein Bytecode eine Exception unter Linux und läßt sich AFAIK auch nicht compilieren.[/QOUTE][OT]Also soweit ich weis, lässt es sich auch unter Linux kompilieren, nur kann es zu Problemen bei der Ausführung kommen, weil Dateien nicht gefunden werden. Es reicht schon, wenn man Windows-Laufwerksbuchstaben verwendet und sich sonst an die Konvention, Slashes statt Backslashes zu verwenden, hält. In Java deuten z.B. [c]C:\\test.dat[/c] und [c]C:/test.dat[/c] auf die selbe Datei.[/OT]

Ach was streite ich mit dir hier eigentlich herum, der noch nicht in Assembler programmiert hat.
Die Plattformunabhängigkeit von C, C++ usw. auf Quellcodeebene ist überall so anerkannt und genau das machen sich Tausende von z.B. Open Source Software Entwicklern zu nutze.
Für die Definition der Plattformunabhängigkeit kannst du ja auch einfach mal die Wikipedia zur Rate ziehen, auch da steht das drin.

Mit dem Link hast's mir aber gegeben... BTW.: Assembler habe ich schon auf dem C-64 (HypraAss) und dem Amiga programmiert, ist aber schon länger her und inzwischen uninteressant geworden. Ausserdem gibt es auch Cross-Assembler sowie Cross-Disassembler (IDA-Pro), da helfen auch die teilweise unfundierten Aussagen dieser weit verbreiteten offenen Ezyklopädie nichts. Von Plattformunabhängigkeit konnte man vor 1995 (Java Geburtsjahr, zuvor OAK nur mal kurz zur Kenntnisnahme erwähnt) nur träumen, kein Mensch bezeichnete eine Sprache als plattformunabhängig - selbst wenn es so ist und nicht zuletzt, weil es so sein muss, weil dieses eben ein Wunschtraum war. Vergleichbar mit den Sprachen der verschiedenen Ländern der Erde und der Mathematik. Letztere ist in jeder Sprache gleich (landesunabhängig). Ebenso verhält es sich mit Bytecode von Just-In-Time-Technologien und Kompilaten anderer Kompiler.

 

[Landei]

Dafür gibt's die limits.h und C Programmierer berücksichtigen das bei der Programmierung, wenn sie plattformunabhängigen Code erzeugen wollen.

Insofern ist das kein Argument, sondern es zeigt eher, daß du nicht viel Erfahrung in C hast.

Genau das ist der Punkt! Natürlich kann man auch in C (auf Quelltextebene) plattformunabhängige Programme schreiben, aber man muss sich aktiv darum kümmen und man muss wissen wie das geht. Macht man einen kleinen Fehler dabei, gibt es die allseits beliebten Segfaults u.s.w. Eine plattformunabhänigige Sprache braucht keine speziellen Bibliotheken nur zur Sicherstellung der Plattformunabhängigkeit.

In anderen Sprachen kann man sich wenigstens bei Primitiven und Systembibliotheken (soweit nicht als plattformspezifisch gekennzeichnet) auf ein plattformunabhängiges Verhalten verlassen, und man schreibt automatisch plattformunabhängige Programme, solange man nicht bewusst auf plattformspezifische Features zugreift - und diese Bereiche sind so klein wie möglich gehalten (so abstrahiert Java etwa von den verschiedenen Thread-Implementierungen der Betriebssysteme, obwohl die sich deutlich unterscheiden).

Ich bleibe dabei: C als plattformunabhängig zu bezeichnen ist absurd. Und mit deinen Aussagen zeigst du, dass du von Java wenig Ahnung hast, sonst wüsstest du, wie wirklich plattformunabhängige Programmierung auszusehen hat.

 

[C_p_unabhäng]

<q>Genau das ist der Punkt! Natürlich kann man auch in C (auf Quelltextebene) plattformunabhängige Programme schreiben, aber man muss sich aktiv darum kümmen und man muss wissen wie das geht. </q>

Das muß man mit Java auch, siehe mein Beispiel mit dem Backslash.

 

[C_p_unabhäng]

Eine plattformunabhänigige Sprache braucht keine speziellen Bibliotheken nur zur Sicherstellung der Plattformunabhängigkeit.

Auch Java braucht eine Java Standard konforme JVM.

Und wenn du JNI verwendest, ist's eh vorbei mit der Plattformunabhängigkeit.

 

[Spacerat]

Und wenn du JNI verwendest, ist's eh vorbei mit der Plattformunabhängigkeit.

Ok... warum? Achtung Fangfrage! XD

 

[schlingel]

Jemand hat da auf der Uni oder in einem Blog (da gab's einiges nach Dennis Ritchis Tod) gehört oder gelesen, dass C und andere Sprachen Plattform unabhängig sind. Warum ist das C? Weil es auf allen Maschinen die selbe Hardware-Architektur voraussetzt.

Dabei ist es egal ob es sich dabei um einen AMD64, x86 oder einen 8085-Prozessor handelt, die Architektur bzw. der prinzipielle Aufbau des Systems ist immer gleich. Das ist bei einigen Sprachen, Assembler natürlich eingeschlossen, nicht so.
Das war übrigens zu Beginn von C auch ein großer Kritikpunkt, wie kann man mit so einer abstrakten Sprache bitte performante Programme schreiben!? Da ist man viel zu weit weg von der eigentlichen Maschine.

Außerdem war es ja dann schon eine richtige Kindergartenübung Programme nur auf das jeweilige Betriebssystem anzupassen. Dort ein DEFINE per CLI Switch aktiviert und da ein anderes Binary verlinkt und schon lief das ganze.

Das was Java verspricht (und auch nicht in dem beschworenen Ausmaß leistet) mit Compile Once, Run Everywhere ist natürlich nicht gemeint. Allerdings, wenn man in C darauf schaut alles schön sauber zu machen, keine Annahmen über die Implementierung der Architektur im Code trifft und auch sonst beim ANSI-Standard bleibt, dann kann man den Code tatsächlich für jede Plattform kompilieren.

Aber so wie es in Java ist, dass man das Programm auf Linux entwickelt und dann auf Windows und Mac deployen kann, das spielt es nicht in C.

 

[Gast2]

Ich möchte mal eine These zu dem Thema Plattformunabhängigkeit in die Runde werfen:

Nicht die Sprache ist plattformunabhängig, sondern die Software. Das geht mitunter in bestimmten Sprachen einfacher oder weniger einfach, jedoch ist es die Software welche plattformunabhängig ist und nicht die zugrundeliegende Sprache!

Die Diskussion sollte demnach mehr in der Richtung geführt werden, welche Sprache ermöglicht einem plattformunabhängige Software zu schreiben?!

 

[Sonecc]

<q>Genau das ist der Punkt! Natürlich kann man auch in C (auf Quelltextebene) plattformunabhängige Programme schreiben, aber man muss sich aktiv darum kümmen und man muss wissen wie das geht. </q>

Das muß man mit Java auch, siehe mein Beispiel mit dem Backslash.

Was hat das mit der Sprache zu tun?
Genau das Problem gibt es in jeder anderen Sprache auch, daher ist das Argument Käse.

Ansonsten, möchte ich kappesf zustimmen. Die Diskussion ist falsch, nicht die Aussagen der meisten hier.
Prinzipiell kann man mit fast allen Sprachen plattformunabhängigen Code schreiben. Die Frage ist nur, wie leicht ist das und wie hilft einem die Plattform dabei?

Die Sprache an sich ist nämlich eigentlich nie Plattformabhängig. Der Quellcode ist überall lesbar.
Die Platform ist der Knackpunkt.

Btw. ist auch Java nicht voll plattformunabhängig. Java Programme sind nur für Plattformen ausführbar, für die eine JVM zur Verfügung steht.

Stackoverflow Frage zu dem Theme der Plattformunabhängigkeit von Java. Vor allem die unterste Antwort finde ich sehr gut

 

[schlingel]

Ich möchte mal eine These zu dem Thema Plattformunabhängigkeit in die Runde werfen:

Das bringt es doch schon auf den Punkt, ohne klare Begriffsdefinition ist die Diskussion fruchtlos. In etwa so sinnvoll wie darüber zu diskutieren was runder ist, ein Kreis oder eine Kugel. Und die Frage ist auch genauso nützlich bei der Entscheidung ob D oder eine andere Sprache.

Die Kernfrage war ja, ob man "Plattform unabhängige" (was immer das auch sei) Sprachen mit "Plattform abhängigen" Sprachen vergleichen solle. Die Antwort ist ganz klar ja. Denn es kommt auf den Zweck und das Ziel der Software an und da muss ich beginnen zu vergleiche, was leistet die Sprache, was das Framework und was der Programmierer und danach suche ich die Sprache aus.
Wenn man jetzt die jeweiligen Problemdomänen anschaut die für D und andere Sprachen (C, Java, C#, C++, Ruby, etc.) in Frage kommen und dann danach fragt was geeigneter ist, wird schnell rauskommen - wie Anfangs im Thread erwähnt - das man kaum zu D greifen wird weil die Unterstützung für andere Sprachen in der selben Domäne einfach besser ist, sei es in der Community, von den Tools oder den bereits gehabten und gelösten Problemen auf SO und anderen Seiten.

Ich weiß nicht wie es euch geht, aber mir persönlich ist es dann egal ob ich einen GC, ein Bytecode-Kompilat oder echten Binärcode oder was auch immer habe, solange das Programm tut was es soll, leicht zu warten und zu erweitern ist und mir möglichst wenig Arbeit macht sobald es mal läuft.

Also warum sollte ich hier nicht die Eigenschaften verschiedenster Systeme und Sprachen miteinander vergleichen?

 

[Spacerat]

Nicht die Sprache ist plattformunabhängig, sondern die Software. Das geht mitunter in bestimmten Sprachen einfacher oder weniger einfach, jedoch ist es die Software welche plattformunabhängig ist und nicht die zugrundeliegende Sprache!

Die Diskussion sollte demnach mehr in der Richtung geführt werden, welche Sprache ermöglicht einem plattformunabhängige Software zu schreiben?!

Richtig! Siehe mein Beispiel mit den Ländern. Sprachen können ohnehin überall je nach Belieben gesprochen werden, ob's einer anderer versteht, ist 'ne andere Frage. Für die Produkte einiger "Sprachen" (Naturwissenschaften) wurden Umgebungen geschaffen, damit sie überall verstanden werden können, aber nicht müssen. In der Software-Entwicklung ist's dasselbe.

@schlingel: Damit hast du vollkommen Recht. Aber wenn von dem Einsatzgebiet direkte Hardware-Zugriffe (Dank der weiträumigen Verteilung entsprechender APIs, lassen wir 3D-Anwendungen mal aussen vor.) gefordert würden, fallen JIT-Technologien schon mal im Vorfeld aus. Die Entscheidung fiele dann nur noch zu Gunsten C, C++, D oder ähnlichem aus. Deswegen meinte ich ja, dass sich JIT-Technologien kaum mit anderen Vergleichen lassen.

 

[freak_007]

Ich weiß nicht warum, aber ich mag die Programmiersprache D nicht. Ich glaube das liegt daran das nicht so viele Libs gibt wie in C oder C++ geschrieben sind. Ich finde Vala ganz gut. Vala ist ziemlich neu und man kann nahezu alle Libs die es auf Linux gibt kann man verwenden(OpenGL, udev, Gtk+ usw .
Gruß,
Freak

 

[schlingel]

@Spacerat - Ja, stimmt. Deswegen habe ich auch von Problemdomänen geschrieben. Nicht alles was man in Java machen kann, kann man sinnvoll mit D machen (JEE etc) aber es gibt doch Bereiche wo es Sinn macht sie zu vergleichen. Das gleiche gilt für C und C++ Einsatzgebiete.
Das was ich sagen wollte war, dass man alle Sprachen miteinander vergleichen sollte die für ein mögliches Programm in Frage kommen. Das können eben auch JIT und nicht JIT getriebene Systeme sein. Siehe z.B. Desktop-Entwicklung.

Also Bindings sind überhaupt kein Argument. Die gibt es für jede Quacksi-Programmiersprache. Ich kenne Vala nicht und möchte auch nicht werten allerdings hat auch D genüged Bindings, eben auch zu den genannten Projekten.

 

[maki]

@Schlingel

C, C++ etc. nennt man "Portierbar" bzw. es geht um die "Portierbarkeit", "Plattformunabhängigkeit" dagegen ist, wie du schon sagtest, eben das "Compile once, run anywhere".

Allersdings sind UI Toolkits ein Stolperstein für Plattformunabhängikeit in Java IME.

 

[mvitz]

...
Dann benuztt doch mal in einer Pfadangabe in Java nen Backslash anstatt nen einfachen Slash und schon wirft dein Bytecode eine Exception unter Linux und läßt sich AFAIK auch nicht compilieren.
...

Und genau aus diesem Grunde abstrahiert Java vom Verzeichnistrenner. Man nimmt unter Java immer den Slash und schon ist es Plattformunabhängig (und das würde ich jetzt nicht als "aktiv plattformunabhängig programmieren" bezeichnen).

 

[MrWhite]

Heutzutage kann ich guten Gewissens sagen, dass ich zu meinem, zu nativem Code kompilierten Programm, einfach immer eine VM mit dazu geben kann. So läuft Platform-Independence heute.

Jaja, so ist das heute. Ihr streitet euch über Kram aus dem letzten Jahrzehnt, Jungs *g*