D erobert die Welt


  • Mod

    rapso schrieb:

    wenn D einfach nur c+=2 waere, alles was c++ kann mit ein bisschen vebesserungen, in co-existenz compilierbar, vielleicht haette es chancen gehabt die c++ user zu absorbieren.

    Ach so meinst du das. Ja, das stimmt wohl.

    Ist ein bisschen ähnlich zu dem, was in den letzten Jahren mit den neuen C++-Standards abgeht. In Babyschritten hin zu einer anderen Sprache.



  • rapso schrieb:

    wenn D einfach nur c+=2 waere, alles was c++ kann mit ein bisschen vebesserungen, in co-existenz compilierbar, vielleicht haette es chancen gehabt die c++ user zu absorbieren.

    Inkluse der Fallen die C++ bietet? Warum?



  • rapso schrieb:

    Marthog schrieb:

    Hach D. Einer der wenigen Faelle, in denen eine Programmiersprache daran scheitert, nicht radikal genug zu sein.

    ich denke die radikalitaet eine neue sprache machen zu wollen ist was die neuen sprachen zum scheitern bringt (als software 2.0). c war anfangs auch nur ein simpler assembler aufsatz. c++ ist nur ein c aufsatz gewesen. ich denke das war der hauptgrund dass sich beide durchsetzten (selbst objective-c hatte schon zu fancy syntax aenderungen und implizites verhalten, als dass es die meisten adaptieren wollten).

    Mit der Radikalitaet habe ich mich eigentlich darauf bezogen, dass viele Sprachen auf ein Feature hin entwickelt werden und am Ende eine kaum benutzbare Sprache mit einem Anwendungszweck rauskommt. Java, C# und Python haben sich ja auch ohne Kompatibilitaet durchgesetzt, einfach weil sie vielseitig einsetzbare Sprachen mit brauchbaren libraries waren.
    D hingegen hat versucht, C++ zu nehmen und vorsichtig einzelne Teile zu veraendern, im Gegensatz zu neuen C++-Standards aber auf Kompatibilitaet keine Ruecksicht nehmen zu muessen. Es ist sicher eine gute Sprache, wahrscheinlich besser als C++, aber als Programmierer nimmt man doch lieber die ganzen kleinen Probleme hin, statt auf Altcode, seine libraries und kompatibilitaet zu anderen Projekten zu verzichten. Entweder man nimmt C++ oder gleich eine ganz andere Sprache.



  • nachtfeuer schrieb:

    Marthog schrieb:

    Hach D. Einer der wenigen Faelle, in denen eine Programmiersprache daran scheitert, nicht radikal genug zu sein.

    radikal unscheinbar käme hin.

    Wenn man sich anhört, was Alexandrescu zuletzt zu D im cpp-Podcast gesagt hat, dann soll D ganz gut compiletime introspektion und metaprogramming unterstützen, was u.a. zu der schnellsten Regex-Engine geführt haben soll, bei der der D-Compiler über D-Metaprogramming aus einer Regex einen optimierten Automaten bastelt. Ich kann mir schon vorstellen, dass das in D weniger ein Krampf ist, zur Compilezeit mit Stringliteralen was zu machen im Vergleich zu den variadischen literal operator templates in C++11.

    Ich mag D trotzdem nicht anfassen. Abgesehen von dem, was man da zur Compilezeit alles anstellen kann, sieht der Rest für mich zu sehr nach einem C++/C# Mischmasch mit komischen Regeln ("transitive const") aus.


  • Mod

    Auch die Chaosforschung hilft verstehen:
    http://123.physics.ucdavis.edu/week_3_files/voss-clarke.pdf

    Meint in etwa: Korrelationsgrad muss in etwa passen.

    Hier wäre was was (in eine andern Sinne) passt: https://www.youtube.com/watch?v=o5m0m_ZG9e8



  • Ich kann mir schon vorstellen, dass das in D weniger ein Krampf ist, zur Compilezeit mit Stringliteralen was zu machen im Vergleich zu den variadischen literal operator templates in C++11.

    Bitte auf C++14 beziehen. Und zur Compilezeit mit Strings zu arbeiten ist gar nicht so unbequem. Hier ist bspw. eine ganze Implementierung eines std::string -Äquivalents.

    Ich mag D trotzdem nicht anfassen.

    Natürlich nicht, schließlich heißt es nicht Rust.



  • Sauber muss die Sprache s schrieb:

    rapso schrieb:

    wenn D einfach nur c+=2 waere, alles was c++ kann mit ein bisschen vebesserungen, in co-existenz compilierbar, vielleicht haette es chancen gehabt die c++ user zu absorbieren.

    Inkluse der Fallen die C++ bietet? Warum?

    da gibt es hauptsaechlich drei gruende weshalb software 2.0 oft scheitert.
    1. mental/psychologisch: weil wir menschen convenience animals sind. das ist eine soziale bzw. psychologische sache. schau z.B. auf betriebssysteme. Windows hat in jeder inkarnation alles neu gemacht. die guten dinge sehen viele erstmal nicht, aber etwas altes was weg ist vermisst man sofort. auf der anderen seite iOS oder Android, was an sich genau so radikal ist eigentlich, aber mental wird es den menschen als "genau wie vorher, jetzt mit vielen neuen extras" verkauft.
    das zwingt natuerlich auf der anderen seite auch dass die entwickler sofort reagieren wenn sie etwas 'verbockt' haben und sie bringen es zurueck oder fixen es. bei Windows ist es "friss oder stirbt... oder warte auf das naechste windows in 5jahren, da fixen wir es vielleicht, falls dich nicht stoert was wir da alles kaputt machen".
    2. technisch: egal wie genial software 2.0 geplant ist, oder wie unglaublich schlecht software 1.0 ist, in software 1.0 steckt viel viel arbeit die du erstmal nachbauen musst in software 2.0, du must alle fehler begehen, du musst alles nochmal testen, im einklang mit dem restlichen system bringen etc.
    3. migrationsaufwand: egal ob es finanzielle kosten (z.b. neue hardware) oder einfach nur geistigen aufwand (einarbeiten). es ist fuer user erstmal zeitverschwendung. da muss das feature aus software 2.0 unglaublich genial sein, um existierende user zum wechseln zu ueberzeugen. eine neue console die 10x so gut graphik liefert? -> 5jahre migrationszeit. neues iphone mit 2x performance -> 2jahre migration. android version+1?

    ich (persoenelich) nenne es das 80% problem. es ist sehr einfach manchmal etwas from scratch hinzuhacken und es lauffaehig zu haben (viel einfacher als im existierendem system zu testen), was die grundidee beweist. das hat aber oft starke einschraenkungen. es dann von 80% auf 90% zu bringen (also auf 'usable') ist eine unmenge von arbeit und dann von 90% auf 100% (also dein feature + alles was die konkurenz kann, damit es ein produkt ist was ueberzeugt) braucht oft jahre.

    von daher denke ich, es ist nett diesen 80% prototype zu machen, aber dann erscheint es mir effizienter einen weg zu finden diesen prototype in das existierende system zu integrieren. ich stimme voll zu dass das architectur maessig ein riesen kopfzerbrechen ist, und auch viel einarbeitung braucht, aber wenn du es hinbekommst, hast du auf einmal eine riesen userbase.

    so laeuft es bei z.B. openGL wo die hardware vendors features per extensions freigeben, manchmal sind diese inkompatibel zu manchen dingen, aber das meiste funzt und jeder der opengl nutzt, kann mit wenig arbeit.

    so gibt es auch oft extensions in compilern (z.b. hat gcc switch support fuer c-sttrings, oder c++1x).



  • Marthog schrieb:

    Mit der Radikalitaet habe ich mich eigentlich darauf bezogen, dass viele Sprachen auf ein Feature hin entwickelt werden und am Ende eine kaum benutzbare Sprache mit einem Anwendungszweck rauskommt. Java, C# und Python haben sich ja auch ohne Kompatibilitaet durchgesetzt, einfach weil sie vielseitig einsetzbare Sprachen mit brauchbaren libraries waren.

    ich nehme die sprachen die du aufzeigst als gegenbeweis zu deiner these wahr. java, c# und python haben sich nicht wegen ihrer sprachlichen qualitaet durchgesetzt (gerade c# war anfangst wie ein java clone, nur von MS), sondern aufgrund von anwendungsgebieten.
    haettest du c++ zu auf eine VM compiliert die Sun/Oracle ueberall in ihr system integriert haetten, waere c++ dort jetzt am laufen. simpler beweis: MS hat genau das mit c# bei sich gemacht.

    oder welches sprach feature von c# macht es gegenueber java ueberlegen als sprache? oder was macht python soviel besser als pearl?

    D hingegen hat versucht, C++ zu nehmen und vorsichtig einzelne Teile zu veraendern, im Gegensatz zu neuen C++-Standards aber auf Kompatibilitaet keine Ruecksicht nehmen zu muessen. Es ist sicher eine gute Sprache, wahrscheinlich besser als C++, aber als Programmierer nimmt man doch lieber die ganzen kleinen Probleme hin, statt auf Altcode, seine libraries und kompatibilitaet zu anderen Projekten zu verzichten. Entweder man nimmt C++ oder gleich eine ganz andere Sprache.

    da stimm ich zu, es gibt keine externen zwaenge D zu nutzen.

    ich denke es ist oft diese kuenstliche platform koplung die eine sprache durchsetzt, aber zu oft ist diese koplung eher politisch gepraegt, nicht technisch. manchmal ist diese politik auch was grossartigen ideen (XNA, WinPhone7, PlaystationSuite) das genick bricht.



  • rapso schrieb:

    ich nehme die sprachen die du aufzeigst als gegenbeweis zu deiner these wahr. java, c# und python haben sich nicht wegen ihrer sprachlichen qualitaet durchgesetzt (gerade c# war anfangst wie ein java clone, nur von MS), sondern aufgrund von anwendungsgebieten.
    [...]
    oder welches sprach feature von c# macht es gegenueber java ueberlegen als sprache? oder was macht python soviel besser als pearl?

    Sie sind Sprachen, die auf praktische Relevanz, also python als uebersichtlichere Alternative zu Pearl, Java als plattformunabhaengige Sprache und C# auf (GUI-)Anwendungsentwicklung unter Windows.

    Es gibt halt viele Leute, die sich hinsetzen und denken, "eine Sprache mit Eigenschaft xy waere nett" und entwickeln dann eine kaum benutzbare, minimale Sprache, die ausser dem nichts kann.
    Die Sprache hat dann z.B. die Grundidee, den eigenen code vollstaendig dynamisch zur Laufzeit veraendern zu koennen. Diese eine Idee ist dogmatisch ausgearbeitet und saemtliches drumherum fehlt, weil z.B. nicht einmal klar ist, wie iteratoren mit diesem "feature" umgehen sollen.



  • rapso schrieb:

    oder welches sprach feature von c# macht es gegenueber java ueberlegen als sprache?

    Properties, generics, events, extension methods, linq, TAP.



  • C>J schrieb:

    rapso schrieb:

    oder welches sprach feature von c# macht es gegenueber java ueberlegen als sprache?

    Properties, generics, events, extension methods, linq, TAP.

    Properties sind Unfug, getter/setter lösen das vollständig und besser.

    Events ebenso unfug, gibt simple Entwurfsmuster dafür.

    Extension methods sind doof wie goto.

    linq ist Fehl am Platz so halb zwischen Sprache und Datenbank.

    TAP ist nur die Antwort auf die inhärente Langsamkeit vobn javaesken Sprachen, also eigentlich Müll, aber wenn man Java gegen C# vergleicht, ein Pluspunkt für C#, fürchte ich. Oder hat's Java schon nachgezogen?



  • volkard schrieb:

    Properties sind Unfug, getter/setter lösen das vollständig und besser.

    a.setValue(a.getValue() + 2); // vs
    a.Value += 2;
    

    Was ist an Variante 1 besser? Einfache Sachen sollten einfach zu schreiben sein. Getter und Setter sind und erzeugen einfach nur Boilerplate Code.

    volkard schrieb:

    Events ebenso unfug, gibt simple Entwurfsmuster dafür.

    For-Schleifen sind Unfug, gibt simple Entwurfsmuster dafür.

    volkard schrieb:

    Extension methods sind doof wie goto.

    Weil?

    volkard schrieb:

    linq ist Fehl am Platz so halb zwischen Sprache und Datenbank.

    Linq hat eigentlich nur am Rande was mit Datenbanken zu tun.

    volkard schrieb:

    TAP ist nur die Antwort auf die inhärente Langsamkeit vobn javaesken Sprachen, also eigentlich Müll, aber wenn man Java gegen C# vergleicht, ein Pluspunkt für C#, fürchte ich.

    TAP hat nichts mit der Geschwindigkeit der Sprache zu tun. Wenn dein Code darauf warten muss dass das Garagentor offen ist, dann muss er das halt. Egal in welcher Sprache (C++ soll ja auch resumable functions bekommen).



  • Es lohnt nicht mit volkard zu "diskutieren" - der lebt noch in der Steinzeit...



  • Arcoth schrieb:

    Ich kann mir schon vorstellen, dass das in D weniger ein Krampf ist, zur Compilezeit mit Stringliteralen was zu machen im Vergleich zu den variadischen literal operator templates in C++11.

    Bitte auf C++14 beziehen. Und zur Compilezeit mit Strings zu arbeiten ist gar nicht so unbequem. Hier ist bspw. eine ganze Implementierung eines std::string -Äquivalents.

    Sieht gut aus. Ich wusste nicht, was constexpr seit C++14 alles so erlaubt. Da fragt man sich langsam, warum man da überall noch constexpr dranschreiben muss. Alexandrescu hatte in seinem letzten Interview (cpp podcast) genau das beklagt.

    Arcoth schrieb:

    Ich mag D trotzdem nicht anfassen.

    Natürlich nicht, schließlich heißt es nicht Rust.

    Keine Ahnung, was Du mit Weglassen meiner Begründung aus dem Zitat und diesem Kommentar bezweckt hast...

    rapso schrieb:

    oder welches sprach feature von c# macht es gegenueber java ueberlegen als sprache?

    Ich habe von diesen zwei genannten Sprachen nur Java benutzt und das ist auch schon eine Weile her. Aber ich denke, die Tatsache, dass man als C# Programmierer auch "Wert-Typen" über struct konstruieren kann und nicht auf "Referenz-Typen" ( class ) beschränkt ist, ist ein Pluspunkt.

    Da gibt es z.B. die Software "SDR#", die genau das ausnutzt und für komplexe Zahlen ein struct verwendet. Diese Software verarbeitet digitale komplexwertige Signale in Echtzeit mit SDR-typischen Abtastraten im Megahertzbereich. In Java könntest Du dir eine Abstraktion der komplexen Zahlen in Form einer Klasse nicht erlauben, weil Dir damit eine Indirektion aufgezwungen wird und Arrays vom Typ Complex[] nur Referenzen speichern würden. Für ein Cache-freundlicheres Speicherlayout könntest Du stattdessen double[] verwenden und Real- und Imaginärteil manuell verzahnen. Das ist doch aber extrem schade, dass man aus Performancegründen in Java auf eine Abstraktion verzichten muss. Dass C# dann noch Operatorüberladung erlaubt, ist hier auch noch praktisch.

    Das ist jetzt das, was mir zuerst zum Thema Java versus C# einfällt.



  • krümelkacker schrieb:

    rapso schrieb:

    oder welches sprach feature von c# macht es gegenueber java ueberlegen als sprache?

    Ich habe von diesen zwei genannten Sprachen nur Java benutzt und das ist auch schon eine Weile her. Aber ich denke, die Tatsache, dass man als C# Programmierer auch "Wert-Typen" über struct konstruieren kann und nicht auf "Referenz-Typen" ( class ) beschränkt ist, ist ein Pluspunkt.

    Ja, Value Semantics und (gewissermaßen als notwendige Folge davon) richtige Generics sind sicherlich die zwei Großen. Leider sind beide Sprachen von GC geplagt...



  • Th69 schrieb:

    Es lohnt nicht mit volkard zu "diskutieren" - der lebt noch in der Steinzeit...

    Ich hüpfe nicht jedem noch so dummen Zeitgeist hinterher.



  • Nachdem ich mir nun endlich mal die Neuerungen in C# 6 angeschaut habe frage ich mich ob die auch nur im entferntesten drüber nachdenken was sie da tun.

    Klar gibt es schöne Features die hinzukommen. Aber zum Beispiel die String Interpolation mittels "$" finde ich sehr suspekt. Ich baue doch in C# keinen String in dem ich fest Variablenbezeichner verwende.

    Beispiel:

    Person person = new Person("Hans", "Peter");
    var data = $"Hallo person.FirstName";
    

    zum Glück ist man aber auch nicht gezwungen die neuen Compiler-Features zu verwenden.

    Im gegenzug dazu finde ich allerdings das neue "nameof()" recht interessant.

    Ich kann also im allgemeinen auch volkard verstehen, wenn er sagt das er nicht jedem Trend hinterer rennt.



  • volkard schrieb:

    Ich hüpfe nicht jedem noch so dummen Zeitgeist hinterher.

    Hast recht! Ich benutze auch noch C++ 98 (und nicht diesen neumodischen Kram ;-).



  • inflames2k schrieb:

    Person person = new Person("Hans", "Peter");
    val data = $"Hallo person.FirstName";
    

    val ?
    Oder meinst du var ?

    Und was hast du gegen String Interpolation?
    Mal abgesehen davon dass es ohne Escape-Character doof ist.

    =>

    Person person = new Person("Hans", "Peter");
    var data = $"Hallo {person.FirstName}";
    

    Sieht doch gleich viel besser (und VIEL weniger problematisch) aus!



  • hustbaer schrieb:

    =>

    Person person = new Person("Hans", "Peter");
    var data = $"Hallo {person.FirstName}";
    

    Sieht doch gleich viel besser (und VIEL weniger problematisch) aus!

    Und das $ ist fast ein Bißchen ist netter als das pythonische .format.

    data = "Hallo {pfn}".format(pfn=person.FirstName)
    

    Wenn ich jetzt sagen würde, daß

    string data = "Hallo " + person.firstName;
    

    auch nicht extrem häßlich wäre, würde ich wieder ausgeschimpft und einen alten Sack genannt werden, gell?

    Th69 darf auch schreiben

    auto data = "Hallo " + person.firstName;
    

    und sich darauf einen runterholen, daß er ein C++11-Mittel benutzt hat.


Anmelden zum Antworten