D?
-
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?
-
sap schrieb:
Was ist an beim VM Deployment wesenlich einfacher als einfach ein Programm das direkt läuft?
ich denke er bezieht auf vms auf verschiedenen betriebssystemen, die mit demselben kompilat arbeiten wozu du im gegensatz für native anwendungen unterschiedliche makefiles aufsetzen musst
-
Ja gut, der Aufwand mit den Makefiles ist schon klar. Aber da geht es ja um das erstellen der Software
Ich bezog mich auf die Einfachheit beim Ausliefern der Software an den Kunden. Da meinte Ich da nativ laufende Programme einfacher zu benutzen sind, da man die im besten Fall nur starten muss.
-
Abgesehen von der ganze DLL-Hölle die man noch dazu braucht *gg*
-
Ihr tut ja so als wäre decompilen immer was schlimmes, aber ich bin ehrlich gesagt froh darüber, dass das oft funktioniert. Debugged euch mal durch proprietäre JDBC-Treiber ohne und einmal mit Decompiler und wiederholt anschließend eure Aussage über "decompilen ist pöse!1" ..
-
Nun, das kommt immer auf den eigenen Standpunkt an. Wenn man Closed Source Software vertreibt, gefällt es einem natürlich wenn andere es nicht deccompilen können.
Vom Standpunkt als Coder selbst sieht man das natürlich anderes.