D erobert die Welt




  • Mod

    Interessant...Jetzt sind die D-Developer entgültig in den 70ern angekommen, yeah!
    😃

    Was kommt als nächstes? D mit Lambdafreak_injection, Math-Goodies und noch mehr Klammern für die elegantere Syntax https://xkcd.com/297/


  • Mod

    Dann gibt es jetzt ja endlich ein D-Programm auf der Welt. Wann kommt wohl das zweite? 🙂

    *duckundweg*



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



  • nachtfeuer schrieb:

    Was kommt als nächstes?

    World Domination.

    First they ignore you.
    Then they laugh at you.
    Then you win.


  • Mod

    Marthog schrieb:

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

    radikal unscheinbar käme hin.



  • 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).

    entsprechend werden neue sprachen zumeist (aber nicht nur!) von opportunistischen nutzern (die mit ihrer bestehenden sprache nicht so richtig zurechtkommen) und neulingen adaptiert. ich denke, dass das c++ sogar staerkt, weil es eine "core user base" hinterlaesst, die tendenziel nicht nur experten in der sprache sind, sondern auch in der software entwicklung an sich.
    ich hab das gefuehl die konkurenz treibt auch den c++ standard vorran, weil andere sprachen doch das eine oder andere haben was 'nett' ist. sie wirken wie versuchssandboxen aus deren vorteilen und fehlern dann neue c++ revisionen entstehen.

    von daher ist es interesant D, Swift, Rust, Go, Loci, VB, C#, Java,... zu sehen. irgendwas interesantes neues haben sie immer, dass c++ adaptieren koennte, um besser zu werden.


  • Mod

    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).

    Im Gegensatz zu C vs. Assembler und C++ vs. C bietet D einfach nicht genug Vorteilhaftes, um einen Umstieg zu rechtfertigen. Wenn Computer und Programmiersprachen heute neu erfunden würden, würde die ganze Welt D programmieren (zumindest in den Bereichen, wo man heute C und C++ einsetzt). Aber da es eine geschichtliche Entwicklung gibt, ist D nur ein etwas besseres C++, aber ohne Killerapplikation.



  • ich meinte eigentlich, dass c und c++ eigentlich keine neue sprache waren, sie hatten etwas 'extra' zu dem was schon da ist. ich kenne c jedenfalls als ziemlich direkt uebersetzenden compiler (ohne viel optimierung). wobei man assembler und c translation units sehr angenehm zusammen linken konnte. in c schrieb man dann den ersten ansatz oder weniger wichtige teile, in assembler dann das kritische.

    vorher war halt alles assembler bzw. macros fuer assembler und da war es relativ rigide. gerade der pre-processor von c half zeit zu sparen (wenn auch der generierte code natuerlich scheusslich langsam war :D)

    c++ war anfangs ziemlich dasselbe, irgendwann konnte halt jeder c compiler auch c++ (bzw eine lustige interpretation von c++). natuerlich war c++ scheusslich langsam, wuerde ein c-coder niemals nie fuer wichtige teile nutzen, aber so ein bisschen high level zeug kann man mit c++ doch angenehmer loesen.

    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.



  • Es würde denk ich eher besser sein, C++ aufzupäppeln (wie man es mit C++11 schon gut hinbekommen hat), statt D durchzusetzen.


  • 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.


Anmelden zum Antworten