D?
-
Sovok schrieb:
Was war denn die Motivation und warum ist Sie nich aufgegangen?
Würd mich direkt mal interessiern
Da gibts verschiedene Sachen, speziell beziehe ich mich aber auf diese Idee, bei der Deklaration einer Variable die Zugriffsweise zu emulieren. Also dass ich halt z.B. schreibe 'int *x', weil ich später per '*x' Zugriff auf das darin gespeicherte int erhalte. Nette Idee, ergibt aber leider ein absolutes Chaos bei verschachtelten Typen, das nicht nur für Anfänger komplex ist.
Außerdem war es von vornherein ein Schuss in den Ofen, auf Schlüsselwörter wie 'var' und 'function' zu verzichten: Klar geht es ohne, aber der Lesbarkeit hift es nicht gerade.
-
CStoll schrieb:
Das heißt, wenn der Compiler keine Matrix!(i,j).opMul(Matrix!(k,i)) findet, verwendet er als nächstes Matrix!(k,i).opMul(Matrix!(i,j)) (und vertauscht mir damit meine Fkatoren, um das Produkt irgendwie doch noch darstellen zu können)
Stimmt, das haben sie IIRC vor einiger Zeit geändert.
Eigentlich ein Widerspruch zu dem Verbot von implizierten Konvertierungen.
-
Konrad Rudolph schrieb:
...
Es ist lustig, wie oft man in diese „Falle“ fällt zu denken, Programmieren habe etwas mit Meinungen oder Vorlieben zu tun. Das ist ja nur äußerst selten der Fall: Informatik, und auch Programmieren, ist eine Wissenschaft, die mit Fakten umgeht....Und es ist lustig, wie oft man in diese "Falle" fällt, zu denken, "Wissenschaft" und "Fakten" hätten nichts mit "Vorlieben" und "Meinungen" zu tun....
Aber das führt zu weit hier ...Gruß,
Simon2.
-
groovemaster schrieb:
Das läuft, wie ich bereits sagte, unter semantischem Zucker.
Und C++ ist lediglich semantischer Zucker für C
-
Konrad Rudolph schrieb:
...
Es ist lustig, wie oft man in diese „Falle“ fällt zu denken, Programmieren habe etwas mit Meinungen oder Vorlieben zu tun. Das ist ja nur äußerst selten der Fall: Informatik, und auch Programmieren, ist eine Wissenschaft, die mit Fakten umgeht....Ich weiß nicht. Man schaue sich doch nur die ganzen Flamewars an, oder Threads die sich über zig Seiten erstrecken und "Welche Einrückung ist besser?" zum Thema haben.
-
ist es objektiv, dass man mit einer Programmiersprache die man besser kennt mehr anfangen kann, als mit einer in dem einem alles fremd vorkommt. Wenn man nun einmal eine Sprache richtig lernt, und dann kommt plötzlich eine andere, die man lernen muss, dann ist diese spracht und die verwendete Systax erstmal schlecht, und es führt zum flamewar. Ist doch ganz logisch, ich werde mich in zukunft aber nicht an sochen diskussionen beteiligen, denn Systax ist meist wirklich nur subjektiv.
-
GPC schrieb:
Konrad Rudolph schrieb:
...
Es ist lustig, wie oft man in diese „Falle“ fällt zu denken, Programmieren habe etwas mit Meinungen oder Vorlieben zu tun. Das ist ja nur äußerst selten der Fall: Informatik, und auch Programmieren, ist eine Wissenschaft, die mit Fakten umgeht....Ich weiß nicht. Man schaue sich doch nur die ganzen Flamewars an, oder Threads die sich über zig Seiten erstrecken und "Welche Einrückung ist besser?" zum Thema haben.
Das sind ja auch meistens sooo substanzielle Diskussionen.
Natürlich gibt es immer und überall Vorlieben (wobei ich mal behaupte, dass die meisten in diesem Bereich durch Gewöhnung erreicht werden). Aber oft werden objektive Kriterien bei Flamewars einfach ignoriert.
-
Konrad Rudolph schrieb:
Aber oft werden objektive Kriterien bei Flamewars einfach ignoriert.
Sonst wärs doch auch kein Flamewar
-
Konrad Rudolph schrieb:
Ahem. Da die Syntax an die von C angelehnt ist, ist sie ja eigentlich schon per Default Schrott.
Naja, das ist wie so oft sehr subjektiv. Es gibt einige Sachen, die ich auch nicht wirklich toll finde, zB die Typ Syntax. Vom Grundprinzip her ist aber die C Syntax nicht schlecht. Sie gefällt mir zumindest besser als so manch anderes. Aber jedem wird man es sowieso nie recht machen können. Common Lisp mit seinen unendlichen Klammerorgien ist sicherlich auch nicht jedermanns Geschmack.
Konrad Rudolph schrieb:
Da gibts verschiedene Sachen, speziell beziehe ich mich aber auf diese Idee, bei der Deklaration einer Variable die Zugriffsweise zu emulieren. Also dass ich halt z.B. schreibe 'int *x', weil ich später per '*x' Zugriff auf das darin gespeicherte int erhalte.
Das hat nichts mit "Zugriffsweise" zu tu, sondern vielmehr mit Indirektion.
Konrad Rudolph schrieb:
Außerdem war es von vornherein ein Schuss in den Ofen, auf Schlüsselwörter wie 'var' und 'function' zu verzichten
Für Leute, die die Sprache nicht kennen, mag das evtl. hilfreich sein. Für Leute, die sie kennen, ist das eher hinderlich. Je weniger Schlüsselwörter eine Sprache für eine gewisse Funktionalität benötigt, desto sauberer ist der Designansatz. Auch wenn es womöglich gar nicht gewollt war.
finix schrieb:
Und C++ ist lediglich semantischer Zucker für C
Kann man so sehen.
Wobei OO oder generische Programmierung schon ein Stückchen darüber hinaus gehen.
-
Konrad Rudolph schrieb:
Außerdem war es von vornherein ein Schuss in den Ofen, auf Schlüsselwörter wie 'var' und 'function' zu verzichten
Für Leute, die die Sprache nicht kennen, mag das evtl. hilfreich sein. Für Leute, die sie kennen, ist das eher hinderlich. Je weniger Schlüsselwörter eine Sprache für eine gewisse Funktionalität benötigt, desto sauberer ist der Designansatz.
Diese Aussage ist so pauschal sicher nicht korrekt. Generell bin ich natürlich auch ein Fan von Minimalismus. Aber gewisse Redundanzen erhöhen die Lesbarkeit schon. Gerade, was Deklarationen angeht, ist C ziemlich defizitär und das bringt dann in C++ Doppeldeutigkeiten zustande, in denen nur durch die Klammerung zwischen Funktionsdeklaration und Konstruktoraufruf unterschieden werden kann. Selbst routinierte C++-Programmierer stolpern über solche Konstrukte. Und nicht nur in C++; ich programmiere beruflich unter anderem C# und selbst hier stolpere ich bisweilen über eine Variablendeklaration.
Es gab zu dem Thema AFAIK sogar eine Studie, die das verdeutlicht haben.
finix schrieb:
Und C++ ist lediglich semantischer Zucker für C
Irgendwie ignoriert diese Aussage das C++-Typensystem komplett.
-
Konrad Rudolph schrieb:
finix schrieb:
Und C++ ist lediglich semantischer Zucker für C
Irgendwie ignoriert diese Aussage das C++-Typensystem komplett.
Was ja auch nicht berauschend ist und kaum besser als das von C. Das ist mal wirklich ein Punkt, wo D einfach mehr zu bieten hat, zum Beispiel durch die typedefs, eine ganz feine Sache.
-
Konrad Rudolph schrieb:
Gerade, was Deklarationen angeht, ist C ziemlich defizitär und das bringt dann in C++ Doppeldeutigkeiten zustande, in denen nur durch die Klammerung zwischen Funktionsdeklaration und Konstruktoraufruf unterschieden werden kann.
liegt aber auch an schlechten Namen. Klassennamen sollten Substantive und Methoden Verben sein. Und wenn manche Leute nicht noch auf die Idee kommen würden die Methoden groß zu schreiben, dann wäre es ganz klar.
-
Optimizer schrieb:
Konrad Rudolph schrieb:
finix schrieb:
Und C++ ist lediglich semantischer Zucker für C
Irgendwie ignoriert diese Aussage das C++-Typensystem komplett.
Was ja auch nicht berauschend ist und kaum besser als das von C. Das ist mal wirklich ein Punkt, wo D einfach mehr zu bieten hat, zum Beispiel durch die typedefs, eine ganz feine Sache.
Schon, aber man hätte imo nicht unbedingt die Bedeutung von typedef ändern sollen, sondern noch ein neues Schlüsselwort einführen. alias wurde ja auch eingeführt.
Oder typedef wie in C(++) lassen und ein neues Schlüsselwort für das Deklarieren semantisch neuer Typen.
-
Konrad Rudolph schrieb:
Diese Aussage ist so pauschal sicher nicht korrekt. Generell bin ich natürlich auch ein Fan von Minimalismus. Aber gewisse Redundanzen erhöhen die Lesbarkeit schon. Gerade, was Deklarationen angeht, ist C ziemlich defizitär und das bringt dann in C++ Doppeldeutigkeiten zustande, in denen nur durch die Klammerung zwischen Funktionsdeklaration und Konstruktoraufruf unterschieden werden kann.
Das ist aber eben ein C++ Problem und kein generelles.
-
groovemaster schrieb:
Konrad Rudolph schrieb:
Diese Aussage ist so pauschal sicher nicht korrekt. Generell bin ich natürlich auch ein Fan von Minimalismus. Aber gewisse Redundanzen erhöhen die Lesbarkeit schon. Gerade, was Deklarationen angeht, ist C ziemlich defizitär und das bringt dann in C++ Doppeldeutigkeiten zustande, in denen nur durch die Klammerung zwischen Funktionsdeklaration und Konstruktoraufruf unterschieden werden kann.
Das ist aber eben ein C++ Problem und kein generelles.
Nein, es ist ein Problem, das auf dieser minimalistischen Syntax fußt. Wenn man von vornherein unterschiedliche Typen von Anweisungen durch Schlüsselwörter abgetrennt hätte, dann wäre das Problem nie vorhanden gewesen. Gut, man kann sicher auch zuweit gehen und wie in BASIC für *jede* Anweisung ein Schlüsslwort verlangen. Aber Sprachkonstrukte gehören einfach ausgewiesen.
-
Konrad Rudolph schrieb:
Nein, es ist ein Problem, das auf dieser minimalistischen Syntax fußt.
wzbw
-
GPC schrieb:
Optimizer schrieb:
Konrad Rudolph schrieb:
finix schrieb:
Und C++ ist lediglich semantischer Zucker für C
Irgendwie ignoriert diese Aussage das C++-Typensystem komplett.
Was ja auch nicht berauschend ist und kaum besser als das von C. Das ist mal wirklich ein Punkt, wo D einfach mehr zu bieten hat, zum Beispiel durch die typedefs, eine ganz feine Sache.
Schon, aber man hätte imo nicht unbedingt die Bedeutung von typedef ändern sollen, sondern noch ein neues Schlüsselwort einführen. alias wurde ja auch eingeführt.
Oder typedef wie in C(++) lassen und ein neues Schlüsselwort für das Deklarieren semantisch neuer Typen.Die Benennung ist doch logisch. Alias steht für den selben Typ, anderer Name, typedef definiert einen neuen Typ. Wie der Name halt irgendwie schon sagt. Dich stört doch nur, dass es anders als in C++ ist.
-
Optimizer schrieb:
GPC schrieb:
Optimizer schrieb:
Konrad Rudolph schrieb:
finix schrieb:
Und C++ ist lediglich semantischer Zucker für C
Irgendwie ignoriert diese Aussage das C++-Typensystem komplett.
Was ja auch nicht berauschend ist und kaum besser als das von C. Das ist mal wirklich ein Punkt, wo D einfach mehr zu bieten hat, zum Beispiel durch die typedefs, eine ganz feine Sache.
Schon, aber man hätte imo nicht unbedingt die Bedeutung von typedef ändern sollen, sondern noch ein neues Schlüsselwort einführen. alias wurde ja auch eingeführt.
Oder typedef wie in C(++) lassen und ein neues Schlüsselwort für das Deklarieren semantisch neuer Typen.Die Benennung ist doch logisch. Alias steht für den selben Typ, anderer Name, typedef definiert einen neuen Typ. Wie der Name halt irgendwie schon sagt. Dich stört doch nur, dass es anders als in C++ ist.
*g* Teils teils. D will ja auch für den C++ Programmierer möglichst wenig Umgewöhnung erfordern, daher empfinde ich das als falschen Schritt. Aber du hast natürlich recht, dass es in D besser ist.
-
Blog zur 1. D Conference: http://leancode.com/category/dlanguage/
Ich wußte gar nicht, dass Alexandrescu an D mitmischt. Vielleicht ist die Sprache doch interessanter als ich dachte.
-
Konrad Rudolph schrieb:
sap schrieb:
Ich muss ehrlich sagen das mir "richtig kompilierte" Sprachen besser gefallen als welche die nur in Bytecode kompiliert wurden und/oder eine Virtual Maschine/Framework brauchen um laufen zu können.
Es ist lustig, wie oft man in diese „Falle“ fällt zu denken, Programmieren habe etwas mit Meinungen oder Vorlieben zu tun. Das ist ja nur äußerst selten der Fall: Informatik, und auch Programmieren, ist eine Wissenschaft, die mit Fakten umgeht. Das soll übrigens *kein* Angriff auf Dich sein, mir passiert das auch häufig, und Du hast ja durchaus auch Argumente geliefert. Trotzdem ist die Formulierung „mir gefällt …“ selten angebracht.
Ich finde schon das da viel Geschmackssache mit reinfällt. Halt eine Bewertung der Fakten, der Vor- und Nachteile und halt geschmackliche Sachen wie Syntax.
Konrad Rudolph schrieb:
- meistens laufen sie schneller
Das ist so nicht mehr korrekt. Das Optimierungspotential moderner VMs ist enorm. Dass C++ nach wie vor schneller ist, liegt *nicht* an der Umsetzung in nativen Code sondern...
Woran es nun genau liegt ist doch egal. Ich habe nicht gemeint das sie schneller sind nur weil sie in nativen Code übersetzt werden auch wenn das so rübergekommen sein mag. Fakt ist und das schreibst du ja selbst das C und C++ nun mal schneller sind und das ist der Punkt warum ich es persönlich mehr mag.
Konrad Rudolph schrieb:
- wenn man seinen Source geheim halten will kann man das so leichter realisieren
Auch das ist irgendwie obsolet. Geheimhaltung des Codes erreicht man heutzutage nur, wenn man nichts (auch kein Kompilat) herausgibt – mit anderen Worten, indem man den Dienst „remote“ zur Verfügung stellt, beispielsweise als WebService.
Das ist sicher eine Methode. Doch der Geschmack der Endanwender ist doch eher noch bei richtigen Desktopanwendungen die keine Internetverbindung benötigen. Also mal als Beispiel worauf ich hinaus will, eine Spracherkennungssoftware, eine Übersetungssoftware, eine Bilderkennungssoftware... Oder Pc Spiele... Oder Leute die keine oder langsame oder teure Internetverbindungen haben... Der Kunde möchte auch sicher nicht das alle diese Daten zur Firma geschickt werden zwecks Datenverarbeitung. Das würde einen riesen Aufschrei geben wegen Datenschutz und möglichem Missbrauch.
Man kann zwar in C oder C++ geschriebene Programme zwar disassemblieren und cracken... Aber was man nicht kann ist den Source ansehen so das er einem viel nützt. Also man kann ich nicht abschauen wie man das schreibt, vieleicht Ansatzweise. Aber wenn man ein Konkurenzprodukt schreiben will dann muss man das schon selbst tun und zwar from scratch. .net/java kann man sogar recht gut decompilen, von der Ausgabe kann man schon erheblich viel mehr schöpfen. Ich hoffe das Du jetzt nicht ankommst und sagst es gibt auch Obsfucatoren, also diskutieren würde ich das gerne aber würde sicher einen neuen Thread lohnen über den Sinn oder Unsinn.
Konrad Rudolph schrieb:
- sie können ohne Installation und out of the box laufen (-> weniger Supportanfragen weil irgendwelche Frameworks nicht installiert sind oder Probleme machen)
Hier hast Du sicherlich einen gültigen Punkt, allerdings finde ich Deployment für eine VM wesentlich einfacher. Das ist aber in der Tat eine persönliche Vorliebe, die einfach auf mangelnder Erfahrung fußt.
Was ist an beim VM Deployment wesenlich einfacher als einfach ein Programm das direkt läuft?