1. Foren
  2. Kommentare
  3. OpenSource-Forum
  4. Alle Kommentare zum Artikel
  5. › Akademy 2014: Idealismus…

Die haben halt ein übliches Problem

  1. Thema
  1. 1
  2. 2

Neues Thema


  1. Die haben halt ein übliches Problem

    Autor: Casandro 10.09.14 - 09:04

    Die haben in C++ begonnen, das zieht nicht wirklich Leute an, die verstehen wie man ein Problem mit möglichst wenig Codezeilen (und somit leicht wartbar und fehlerarm) löst. Deshalb haben die gigantisch viel Code, der jetzt weiter gepflegt werden will... das ist natürlich schwierig.

    Google hat im Prinzip das gleiche Problem mit Android (allerdings hier mit Java), das ist inzwsichen so groß, dass nur noch Google das warten kann. Google hat halt genügend Arbeitskraft für so was, als echte Freie Software könnte das Projekt aber nicht überleben.

  2. Re: Die haben halt ein übliches Problem

    Autor: cr_app 10.09.14 - 09:42

    Casandro schrieb:
    --------------------------------------------------------------------------------
    > Die haben in C++ begonnen, das zieht nicht wirklich Leute an, die verstehen
    > wie man ein Problem mit möglichst wenig Codezeilen (und somit leicht
    > wartbar und fehlerarm) löst. Deshalb haben die gigantisch viel Code, der
    > jetzt weiter gepflegt werden will... das ist natürlich schwierig.

    Das zieht nicht wirklich Leute an, weil du dafür mehr drauf haben musst als ein Script Kiddie. Kannst du mal bitte noch darstellen warum man in C++/Qt ein Problem nicht effizient und kompakt lösen kann? Du scheinst dich da ja richtig gut auszukennen.

    >
    > Google hat im Prinzip das gleiche Problem mit Android (allerdings hier mit
    > Java), das ist inzwsichen so groß, dass nur noch Google das warten kann.
    > Google hat halt genügend Arbeitskraft für so was, als echte Freie Software
    > könnte das Projekt aber nicht überleben.

    Google hat ein Problem mit Android was den Umfang des Codes angeht? Könntest du auch hier bitte nochmal eruieren was genau das Problem mit Android ist, besonders im Bezug auf Java, danke.

    Man wird das Gefühl nicht los, dass eigentlich ein Post ist, der Freitags hätte erscheinen sollen.

  3. Re: Die haben halt ein übliches Problem

    Autor: pythoneer 10.09.14 - 10:22

    Die Ernsthaftigkeit ist in keinem deiner beiden Punkte erkennbar. Ich kann mir auch kaum erklären wie du darauf kommst und was für dich die Alternative wäre. Sei mir nicht böse aber es klingt so als hättest du seit zwei Wochen angefangen Python zu lernen und findest jetzt alle etablierten Sprachen mit denen die größten Softwareprojekte überhaupt auf die Beine gestellt werden und für die es ausgezeichnete und erprobte Abläufe gibt für überholt, weil du ganz schnell mal nen Skript zusammen tüfteln kannst.

  4. Re: Die haben halt ein übliches Problem

    Autor: Nephtys 10.09.14 - 10:32

    cr_app schrieb:
    --------------------------------------------------------------------------------
    > Casandro schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Die haben in C++ begonnen, das zieht nicht wirklich Leute an, die
    > verstehen
    > > wie man ein Problem mit möglichst wenig Codezeilen (und somit leicht
    > > wartbar und fehlerarm) löst. Deshalb haben die gigantisch viel Code, der
    > > jetzt weiter gepflegt werden will... das ist natürlich schwierig.
    >
    > Das zieht nicht wirklich Leute an, weil du dafür mehr drauf haben musst als
    > ein Script Kiddie. Kannst du mal bitte noch darstellen warum man in C++/Qt
    > ein Problem nicht effizient und kompakt lösen kann? Du scheinst dich da ja
    > richtig gut auszukennen.


    Ich muss hier mal eingreifen. Wenn jemand den Unterschied zwischen "wirklichen" Hochsprachen und C++/Qt nicht sieht, dann hilft noch so viel Argumentieren nichts.
    Fakt ist: C/C++ erzeugt zu viele Bugs bei der Entwicklung, und ist nur schwer zu testen.

    Vergleichen wir es doch mal zB mit Haskell (oder Ocaml, oder .NET, oder irgendwas). Da kann man schnell und einfach komplizierte Programme bauen, es bleibt aber einfach Fehler zu finden, und Tests zu schreiben. Zudem federt ein Garbage Collector Anfängerfehler aus.

    Dennoch wird vor allem in der Linux Welt weiter so viel C++ verwendet wie nur geht. Warum? Primär aus Masochismus. Und aus Tradition. Und aus Gruppenzwang. Es gibt ein paar gute Programmierer, die sehr schnell komplexe Programme schreiben können und alle Fehler schnell gefixxt haben. Das sind dann die Positiv-Beispiele. Jetzt kommt noch das Totschlagargument, dass ein C++-Programm immer schneller ist als eines in einer anderen Sprache, und schon zwingst du quasi alle Anfänger das so zu machen.

    Qt ist dabei nicht schlecht. Aber es gibt Qt-Bindings in so vielen Sprachen... warum muss dann der Zentralcode in C++ geschrieben werden? Es sollte jedem klar sein, dass nativer Code für Nicht-HPC-Programme nichts auf PCs zu suchen hat (sondern nur auf Geräten oder Applikationen, wo man wirklich alle Ressourcen ausnutzen muss, was nicht der Fall ist bei fast allen KDE-Anwendungen).

    Und wer den elementaren Schwachpunkt von nativem Code nicht sieht, mit dem kann nicht diskutiert werden. Das wäre als ob man mit jemandem über Astrophysik redet, der noch der festen Meinung ist, dass die Erde flach ist.

  5. Re: Die haben halt ein übliches Problem

    Autor: hum4n0id3 10.09.14 - 11:46

    Nephtys schrieb:
    --------------------------------------------------------------------------------
    > Fakt ist: C/C++ erzeugt zu viele Bugs bei der Entwicklung, und ist nur
    > schwer zu testen.
    >

    Der Programmierer erzeugt die Bugs nicht der Compiler.

    > Vergleichen wir es doch mal zB mit Haskell (oder Ocaml, oder .NET, oder
    > irgendwas). Da kann man schnell und einfach komplizierte Programme bauen,
    > es bleibt aber einfach Fehler zu finden, und Tests zu schreiben. Zudem
    > federt ein Garbage Collector Anfängerfehler aus.
    >

    Das liegt daran wie diese Sprachen entwickelt wurden. Diese Sprachen versuchen von vornherein dem Entwickler unter die Arme zu greifen und somit Fehler zu vermeiden. C++ wurde zu einer Zeit entwickelt, wo das noch gar nicht im vordergrund stand. Neue Versionen gehen jedoch einen ebenfalls modernen Weg.

    > Dennoch wird vor allem in der Linux Welt weiter so viel C++ verwendet wie
    > nur geht. Warum? Primär aus Masochismus. Und aus Tradition. Und aus
    > Gruppenzwang. Es gibt ein paar gute Programmierer, die sehr schnell
    > komplexe Programme schreiben können und alle Fehler schnell gefixxt haben.
    > Das sind dann die Positiv-Beispiele. Jetzt kommt noch das
    > Totschlagargument, dass ein C++-Programm immer schneller ist als eines in
    > einer anderen Sprache, und schon zwingst du quasi alle Anfänger das so zu
    > machen.
    >
    Was wohl vielmehr mit der Geschichte von Unix zusammen hängt und weniger mit Masochismus usw.

    > Qt ist dabei nicht schlecht. Aber es gibt Qt-Bindings in so vielen
    > Sprachen... warum muss dann der Zentralcode in C++ geschrieben werden? Es
    > sollte jedem klar sein, dass nativer Code für Nicht-HPC-Programme nichts
    > auf PCs zu suchen hat (sondern nur auf Geräten oder Applikationen, wo man
    > wirklich alle Ressourcen ausnutzen muss, was nicht der Fall ist bei fast
    > allen KDE-Anwendungen).
    >

    Momentan nutze ich lieber Visual C++ und das ist schon gräßlich. Qt macht sogar noch weniger Spaß. Für Anwendungen nutze ich viel lieber Java oder C#.

    > Und wer den elementaren Schwachpunkt von nativem Code nicht sieht, mit dem
    > kann nicht diskutiert werden. Das wäre als ob man mit jemandem über
    > Astrophysik redet, der noch der festen Meinung ist, dass die Erde flach
    > ist.

    Hä?

  6. Re: Die haben halt ein übliches Problem

    Autor: derats 10.09.14 - 12:04

    Nephtys schrieb:
    --------------------------------------------------------------------------------
    > cr_app schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Casandro schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Die haben in C++ begonnen, das zieht nicht wirklich Leute an, die
    > > verstehen
    > > > wie man ein Problem mit möglichst wenig Codezeilen (und somit leicht
    > > > wartbar und fehlerarm) löst. Deshalb haben die gigantisch viel Code,
    > der
    > > > jetzt weiter gepflegt werden will... das ist natürlich schwierig.
    > >
    > > Das zieht nicht wirklich Leute an, weil du dafür mehr drauf haben musst
    > als
    > > ein Script Kiddie. Kannst du mal bitte noch darstellen warum man in
    > C++/Qt
    > > ein Problem nicht effizient und kompakt lösen kann? Du scheinst dich da
    > ja
    > > richtig gut auszukennen.
    >
    > Ich muss hier mal eingreifen. Wenn jemand den Unterschied zwischen
    > "wirklichen" Hochsprachen und C++/Qt nicht sieht, dann hilft noch so viel
    > Argumentieren nichts.
    > Fakt ist: C/C++ erzeugt zu viele Bugs bei der Entwicklung, und ist nur
    > schwer zu testen.
    >
    > Vergleichen wir es doch mal zB mit Haskell (oder Ocaml, oder .NET, oder
    > irgendwas). Da kann man schnell und einfach komplizierte Programme bauen,
    > es bleibt aber einfach Fehler zu finden, und Tests zu schreiben. Zudem
    > federt ein Garbage Collector Anfängerfehler aus.
    >
    > Dennoch wird vor allem in der Linux Welt weiter so viel C++ verwendet wie
    > nur geht. Warum? Primär aus Masochismus. Und aus Tradition. Und aus
    > Gruppenzwang. Es gibt ein paar gute Programmierer, die sehr schnell
    > komplexe Programme schreiben können und alle Fehler schnell gefixxt haben.
    > Das sind dann die Positiv-Beispiele. Jetzt kommt noch das
    > Totschlagargument, dass ein C++-Programm immer schneller ist als eines in
    > einer anderen Sprache, und schon zwingst du quasi alle Anfänger das so zu
    > machen.
    >
    > Qt ist dabei nicht schlecht. Aber es gibt Qt-Bindings in so vielen
    > Sprachen... warum muss dann der Zentralcode in C++ geschrieben werden? Es
    > sollte jedem klar sein, dass nativer Code für Nicht-HPC-Programme nichts
    > auf PCs zu suchen hat (sondern nur auf Geräten oder Applikationen, wo man
    > wirklich alle Ressourcen ausnutzen muss, was nicht der Fall ist bei fast
    > allen KDE-Anwendungen).
    >
    > Und wer den elementaren Schwachpunkt von nativem Code nicht sieht, mit dem
    > kann nicht diskutiert werden. Das wäre als ob man mit jemandem über
    > Astrophysik redet, der noch der festen Meinung ist, dass die Erde flach
    > ist.

    Ich zitier das nur mal, falls der Autor später wiederkommt und es wegeditiert.

    > Ich muss hier mal eingreifen. Wenn jemand den Unterschied zwischen
    > "wirklichen" Hochsprachen und C++/Qt nicht sieht, dann hilft noch so viel
    > Argumentieren nichts.

    Ah ja, die übliche Unterscheidung von falschen und echten Hochsprachen, typischerweise nur bei Trollen und Unwissenden anzutreffen. Gänzlich absent in der akademischen Betrachtung oder professionellen Evaluation von Programmiersprachen.

    > Fakt ist: C/C++ erzeugt zu viele Bugs bei der Entwicklung, und ist nur
    > schwer zu testen.

    Ziemlicher Schwachsinn. C und C++ kann man wunderbar testen, das funktioniert exakt genau so wie in jeder anderen modernen Sprache auch — Unit-Test - Funktionstest - Systemtest - Integ-Test, bevorzugt alles auf nem CI-Server "in Echtzeit", für jeden Commit. Beim Entwickeln (zwischen Commits) lässt man dann meist nur die Unit-Tests laufen, weil die schnell sind (wie überall sonst auch), während Tests höherer Ebene länger brauchen (wie überall sonst auch).
    Dazu noch die statische Analyse (cppcheck, clang-analyze, PREfast)...

    Wer modernes C++ schreibt, schreibt vielleicht einmal delete... pro Projekt. Memory Management in C++ macht man heutzutage nicht mehr von Hand, sondern zu 99 % automatisiert und davon etwa 50 % statisch zur Compilezeit, der Rest ist pseudo-statisch (Objektbäume wie in Qt und anderen Frameworks üblich) oder dynamisch (Stichwort shared ptr).
    Durch die Möglichkeiten der Metaprogrammierung und Templates lassen sich heutzutage mehr Fehler beim Kompilieren finden als je zuvor, vgl. die Neuerungen in Qt 5's Signal/Slot-System ... connect() kann zur Compilezeit statisch vorhersagen, ob eine Verbindung zustande kommt!

    > Vergleichen wir es doch mal zB mit Haskell (oder Ocaml, oder .NET, oder
    > irgendwas). Da kann man schnell und einfach komplizierte Programme bauen,
    > es bleibt aber einfach Fehler zu finden, und Tests zu schreiben.

    Aha?

    Die Schwierigkeit beim Schreiben komplexer Anwendungen ist mitnichten die Sprache. Die kommt erst beim letzten, einfachsten Schritt ins Spiel (Codephase). 95 % aller Fehler passieren in den vorigen Phasen eines Projekts, enorm häufig z.B. bei der Erstellung der Spezifikationen. Die sind nämlich wirklich kompliziert, aber das scheint dir nicht bekannt zu sein, du scheinst keinen Hintergrund mit Software-Engineering zu haben, sonst wüsstest du das.

    Die Schwierigkeit beim Schreiben von Tests ist wieder mitnichten die Sprache. Tests schreibt man überall gleich, das ist praktisch unabhängig davon, ob das jetzt C++, Java, Python oder .NET ist. Die Schwierigkeit beim Schreiben von Tests ist wieder vor dem eigentlichen Schreiben: Die Erstellung der Testfälle. Das ist nämlich ein strukturierter Prozess, Stichworte für dich zum Nachlesen Überdeckungskriterien, Parameterräume und -Klassen. Der erfordert zum einen genannte Kriterien (Nein , in der Praxis schreiben nur unfähige Leute Unit-Tests "einfach so") und etwas Kreativität (Welche Boundary-Übergänge gibt es? Wo werden typischerweise Fehler gemacht?). Coverage-Tools unterstützen dabei, teilweise.

    > Zudem
    > federt ein Garbage Collector Anfängerfehler aus.

    Welche denn? Objekt vergessen zu löschen, weil man 90er Jahre C++ schreibt, wie es nicht mehr gelehrt und nirgendwo empfohlen wird? Gleiche Problematik übrigens bei C.

    > Dennoch wird vor allem in der Linux Welt weiter so viel C++ verwendet wie
    > nur geht. Warum? Primär aus Masochismus. Und aus Tradition. Und aus
    > Gruppenzwang. Es gibt ein paar gute Programmierer, die sehr schnell
    > komplexe Programme schreiben können und alle Fehler schnell gefixxt haben.

    C++ ist mitnichten ein Phänomen der Linux-Welt, ich weiß nicht, woher du das hast. Extrem viel im kommerziellen Bereich wird in C++ gemacht, C++ und Java sind DIE kommerziell genutzten Sprachen schlechthin.

    > Das sind dann die Positiv-Beispiele. Jetzt kommt noch das
    > Totschlagargument, dass ein C++-Programm immer schneller ist als eines in
    > einer anderen Sprache, und schon zwingst du quasi alle Anfänger das so zu
    > machen.

    Das ist meistens keine Überlegung dabei. Die Auswahl einer Programmiersprache für ein Projekt (hint: viele große Projekte nutzen mehr als eine Sprache, häufige Kombination ist z.B. C++ und Java) basiert auf ganz anderen Kriterien.

    > Qt ist dabei nicht schlecht. Aber es gibt Qt-Bindings in so vielen
    > Sprachen... warum muss dann der Zentralcode in C++ geschrieben werden? Es
    > sollte jedem klar sein, dass nativer Code für Nicht-HPC-Programme nichts
    > auf PCs zu suchen hat (sondern nur auf Geräten oder Applikationen, wo man
    > wirklich alle Ressourcen ausnutzen muss, was nicht der Fall ist bei fast
    > allen KDE-Anwendungen).

    Kannst du auch eine Begründung für diese These liefern?

    Wahrscheinlich nicht.

    > Und wer den elementaren Schwachpunkt von nativem Code nicht sieht, mit dem
    > kann nicht diskutiert werden. Das wäre als ob man mit jemandem über
    > Astrophysik redet, der noch der festen Meinung ist, dass die Erde flach
    > ist.

    Ich befürchte eher, dass du von Software Engineering schlicht keine Ahnung hast und du zu der Gruppe von Leuten gehörst, die glauben, dass die meiste Zeit bei der Entwicklung von Software fürs Coden draufgeht.

  7. Re: Die haben halt ein übliches Problem

    Autor: pythoneer 10.09.14 - 12:08

    Nephtys schrieb:
    --------------------------------------------------------------------------------
    > Und wer den elementaren Schwachpunkt von nativem Code nicht sieht, mit dem
    > kann nicht diskutiert werden. Das wäre als ob man mit jemandem über
    > Astrophysik redet, der noch der festen Meinung ist, dass die Erde flach
    > ist.

    Super Satire! Der letzte Absatz hat mir dann den Rest gegeben. Du solltest Stand-up-Comedy werden, bei diesem Talent – zumindest ich konnte mir das Lachen nicht mehr verkneifen.

  8. Re: Die haben halt ein übliches Problem

    Autor: Hello_World 10.09.14 - 12:45

    > Kannst du mal bitte noch darstellen warum man in C++/Qt ein Problem nicht effizient und kompakt lösen kann?
    Weil die Sprache für einfache, kompakte Lösungen schlicht nicht geeignet ist. Nehmen wir ein ganz einfaches Beispiel: die Berechnung der Teillisten einer Liste (für [1,2] z. B.[[],[1],[2],[1,2]]) . In Haskell:
    pow [] = [[]]
    pow (x:xs) = do
    a <- pow xs
    [a, x:a]

    Und jetzt schreib das mal in C++. Jede Wette, dass Du mindestens dreimal so viel Code brauchst, und wahrscheinlich auch mehr Speicher.

  9. Re: Die haben halt ein übliches Problem

    Autor: Hello_World 10.09.14 - 12:47

    > Und wer den elementaren Schwachpunkt von nativem Code nicht sieht, mit dem kann nicht diskutiert werden. Das wäre als ob man mit jemandem über Astrophysik redet, der noch der festen Meinung ist, dass die Erde flach ist.
    Ob nativ oder nicht ist vollkommen unerheblich, Haskell und Ocaml werden auch in nativen Code übersetzt.

  10. Re: Die haben halt ein übliches Problem

    Autor: pythoneer 10.09.14 - 14:50

    Hello_World schrieb:
    --------------------------------------------------------------------------------
    > Und jetzt schreib das mal in C++. Jede Wette, dass Du mindestens dreimal so
    > viel Code brauchst, und wahrscheinlich auch mehr Speicher.

    Warst du auf der gleichen Komikerschule wie Nephtys? Für sowas zahlt man normalerweise viel Geld, das gibt es bei Golem heute alles kostenlos – ich bin begeistert!

  11. Re: Die haben halt ein übliches Problem

    Autor: derats 10.09.14 - 14:56

    pythoneer schrieb:
    --------------------------------------------------------------------------------
    > Hello_World schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Und jetzt schreib das mal in C++. Jede Wette, dass Du mindestens dreimal
    > so
    > > viel Code brauchst, und wahrscheinlich auch mehr Speicher.
    >
    > Warst du auf der gleichen Komikerschule wie Nephtys? Für sowas zahlt man
    > normalerweise viel Geld, das gibt es bei Golem heute alles kostenlos
    > – ich bin begeistert!

    Weiß doch jeder, wichtigste Codemetrik ist _natürlich_ die Anzahl der Zeilen! (Kommentare mitgezählt)

  12. Re: Die haben halt ein übliches Problem

    Autor: Hello_World 10.09.14 - 15:25

    derats schrieb:
    --------------------------------------------------------------------------------
    > Ah ja, die übliche Unterscheidung von falschen und echten Hochsprachen,
    > typischerweise nur bei Trollen und Unwissenden anzutreffen. Gänzlich absent
    > in der akademischen Betrachtung oder professionellen Evaluation von
    > Programmiersprachen.
    Bei manchen Sprachen programmiert man auf einem höheren Abstraktionsniveau als bei anderen, das ist eine Tatsache, die Du nicht bestreiten kannst.

    > Ziemlicher Schwachsinn. C und C++ kann man wunderbar testen, das
    > funktioniert exakt genau so wie in jeder anderen modernen Sprache auch
    Prinzipiell schon, aber C und C++ fördern eine Programmierweise, die tendenziell zu schlechter Testbarkeit führt, z. B. durch die Exzessive Verwendung von State, wo unveränderliche Datenstrukturen besser wären.

    > Wer modernes C++ schreibt, schreibt vielleicht einmal delete... pro
    > Projekt. Memory Management in C++ macht man heutzutage nicht mehr von Hand,
    > sondern zu 99 % automatisiert und davon etwa 50 % statisch zur Compilezeit,
    > der Rest ist pseudo-statisch (Objektbäume wie in Qt und anderen Frameworks
    > üblich) oder dynamisch (Stichwort shared ptr).
    Ja, bis man dann irgendwo einen Referenzzyklus hat und doch wieder was leakt. Mal ganz abgesehen davon, dass Reference Counting erheblichen Overhead verursacht, besonders wenn das dann noch threadsicher passieren soll.

    > Durch die Möglichkeiten der Metaprogrammierung und Templates lassen sich
    > heutzutage mehr Fehler beim Kompilieren finden als je zuvor, vgl. die
    > Neuerungen in Qt 5's Signal/Slot-System ... connect() kann zur Compilezeit
    > statisch vorhersagen, ob eine Verbindung zustande kommt!
    Ach ja, die ach so tollen Templates. Nur sind die bei näherer Betrachtung gar nicht so toll. Bei Templates kann keine Typprüfung stattfinden, die findet erst nach der Instanziierung statt – der Versuch, das mit Concepts zu beheben ist ja gescheitert. Weiter geht es damit, dass Bugs in Templates nicht behoben werden können, indem eine neue DLL ausgeliefert wird, nein, man muss den Client-Code neu kompilieren, großartig. Und die Compilezeiten sind sowieso jenseits von gut und böse, weil es nach wie vor kein Modulsystem gibt. Das ist Mäusescheiße.

    > Aha?
    >
    > Die Schwierigkeit beim Schreiben komplexer Anwendungen ist mitnichten die
    > Sprache.
    Doch, das ist auch ein Problem.

    > Die kommt erst beim letzten, einfachsten Schritt ins Spiel
    > (Codephase). 95 % aller Fehler passieren in den vorigen Phasen eines
    > Projekts, enorm häufig z.B. bei der Erstellung der Spezifikationen.
    Ach, was für ein Quatsch. Bei Softwareentwicklung kann man nicht alles im voraus planen, sehr häufig passiert es, dass Probleme erst bei der Implementierung richtig erkannt werden. Ganz zu schweigen davon, dass Anforderungen praktisch nie zu Beginn des Projekts komplett feststehen, sondern sich ständig weiterentwickeln. Du denkst in Wasserfallmodell-Kategorien, und dieses Modell funktioniert für moderne Softwareentwicklung vorn und hinten nicht. Zudem kommt eine Programmiersprache mitnichten nur bei der Implementierung zum Einsatz: bei modernen Programmiersprachen kann man große Teile des Designs mit dem Typsystem ausdrücken.

    > Die Schwierigkeit beim Schreiben von Tests ist wieder mitnichten die
    > Sprache. Tests schreibt man überall gleich, das ist praktisch unabhängig
    > davon, ob das jetzt C++, Java, Python oder .NET ist.
    Irrtum, Mocking und ähnliches ist in manchen Sprachen wesentlich einfacher als in anderen.

    > Welche denn? Objekt vergessen zu löschen, weil man 90er Jahre C++ schreibt,
    > wie es nicht mehr gelehrt und nirgendwo empfohlen wird?
    Schön wär's! De facto wurden Smartpointer doch erst mit C++11 und rvalue-Referenzen vernünftig benutzbar. Mal ganz abgesehen davon, dass man damit auch keine Referenzzyklen aufräumen kann. Wenn ich mir beim Programmieren Gedanken machen muss, ob irgendwo Referenzzyklen auftauchen, läuft irgendwas gewaltig falsch.

    > Gleiche Problematik
    > übrigens bei C.
    C hat kein RAII, da kommt man um malloc und free (oder vergleichbares) noch viel weniger herum als in C++.

  13. Re: Die haben halt ein übliches Problem

    Autor: derats 10.09.14 - 15:58

    Hello_World schrieb:
    --------------------------------------------------------------------------------
    > derats schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Ah ja, die übliche Unterscheidung von falschen und echten Hochsprachen,
    > > typischerweise nur bei Trollen und Unwissenden anzutreffen. Gänzlich
    > absent
    > > in der akademischen Betrachtung oder professionellen Evaluation von
    > > Programmiersprachen.
    > Bei manchen Sprachen programmiert man auf einem höheren Abstraktionsniveau
    > als bei anderen, das ist eine Tatsache, die Du nicht bestreiten kannst.
    >
    > > Ziemlicher Schwachsinn. C und C++ kann man wunderbar testen, das
    > > funktioniert exakt genau so wie in jeder anderen modernen Sprache auch
    > Prinzipiell schon, aber C und C++ fördern eine Programmierweise, die
    > tendenziell zu schlechter Testbarkeit führt, z. B. durch die Exzessive
    > Verwendung von State, wo unveränderliche Datenstrukturen besser wären.

    Tut mir leid, aber ich jemanden nicht wirklich ernst nehmen, der "C und C++ fördern [irgendwas]" schreibt. C und C++ haben de-facto nix miteinander zu tun, außer dass eine gewisse Menge von C in C++ enthalten ist. Aber insbesondere Ansätze und Möglichkeiten sind fundamental unterschiedlich.

    In state-of-the-art C++ werden z.B. häufig eingebettete DSLs benutzt, was ohne Templates nicht oder nicht so komfortabel möglich wäre. Und gerade besagte DSLs vereinfachen die Testbarkeit oft enorm, vereinfachen Code und ermöglichen gleichzeitig gezielte Optimierung.

    > > Wer modernes C++ schreibt, schreibt vielleicht einmal delete... pro
    > > Projekt. Memory Management in C++ macht man heutzutage nicht mehr von
    > Hand,
    > > sondern zu 99 % automatisiert und davon etwa 50 % statisch zur
    > Compilezeit,
    > > der Rest ist pseudo-statisch (Objektbäume wie in Qt und anderen
    > Frameworks
    > > üblich) oder dynamisch (Stichwort shared ptr).
    > Ja, bis man dann irgendwo einen Referenzzyklus hat und doch wieder was
    > leakt. Mal ganz abgesehen davon, dass Reference Counting erheblichen
    > Overhead verursacht, besonders wenn das dann noch threadsicher passieren
    > soll.

    Interessant, Referenzzyklen sind ausschließlich bei GCs ein Problem, nicht bei Objektbäumen oder shared ptrs. Natürlich ist Refcounting langsamer, v.a., wenn man für jeden Zugriff oder jeden Scope den Refcount anfässt. Deswegen ist es, wenn man denn shared ptrs der stdlib oder einer anderen Lib nutzt, ratsam Referenzen über einen äußeren Scope zu schachteln. Das ist sicher _und_ schnell.

    Außerdem sei natürlich erwähnt, dass du auch in C++ mit einem GC arbeiten kannst oder gänzlich andere MM-Schemen verwenden kannst, etwa Pools von Objekten.

    > > Durch die Möglichkeiten der Metaprogrammierung und Templates lassen sich
    > > heutzutage mehr Fehler beim Kompilieren finden als je zuvor, vgl. die
    > > Neuerungen in Qt 5's Signal/Slot-System ... connect() kann zur
    > Compilezeit
    > > statisch vorhersagen, ob eine Verbindung zustande kommt!
    > Ach ja, die ach so tollen Templates. Nur sind die bei näherer Betrachtung
    > gar nicht so toll. Bei Templates kann keine Typprüfung stattfinden, die
    > findet erst nach der Instanziierung statt – der Versuch, das mit
    > Concepts zu beheben ist ja gescheitert. Weiter geht es damit, dass Bugs in
    > Templates nicht behoben werden können, indem eine neue DLL ausgeliefert
    > wird, nein, man muss den Client-Code neu kompilieren, großartig. Und die
    > Compilezeiten sind sowieso jenseits von gut und böse, weil es nach wie vor
    > kein Modulsystem gibt. Das ist Mäusescheiße.

    Von PCHs scheinst du noch nix gehört zu haben, hm?
    Prinzipbedingt kann man Templates nicht extern linken (etwa per DLL), das ist aber eigentlich jedem klar, der sich das fünf Minuten angesehen hat.
    Vollständige Spezialisierungen kann man _natürlich_ extern linken, was auch oft gemacht wird, aber eben nicht immer sinnvoll ist.
    Und natürlich kann man Typprüfungen in Templates machen, das ist nur weit weniger komfortabel in "vanilla" C++, als es mittels Concepts oder externer Bibliotheken ginge, was natürlich nicht schön ist. Aber vielleicht wird das ja mit C++17 was, das wäre sehr schön.

    > > Aha?
    > >
    > > Die Schwierigkeit beim Schreiben komplexer Anwendungen ist mitnichten
    > die
    > > Sprache.
    > Doch, das ist auch ein Problem.

    Aber nicht _das_ Problem, wie du es hier darstellst. Dass es vielleicht eher nicht klappt in Brainfuck die neue Steueranwendung zu schreiben... ja, wahrscheinlich. Dass das Projekt scheitert, weil <random Hochsprache> statt <random anderer Hochsprache> verwendet wurde, ist eher unwahrscheinlich. Ob das am Ende in C++ oder Java geschrieben wird, ist eine Detailfrage.

    > > Die kommt erst beim letzten, einfachsten Schritt ins Spiel
    > > (Codephase). 95 % aller Fehler passieren in den vorigen Phasen eines
    > > Projekts, enorm häufig z.B. bei der Erstellung der Spezifikationen.
    > Ach, was für ein Quatsch. Bei Softwareentwicklung kann man nicht alles im
    > voraus planen, sehr häufig passiert es, dass Probleme erst bei der
    > Implementierung richtig erkannt werden. Ganz zu schweigen davon, dass
    > Anforderungen praktisch nie zu Beginn des Projekts komplett feststehen,
    > sondern sich ständig weiterentwickeln.

    Ack

    > Du denkst in
    > Wasserfallmodell-Kategorien, und dieses Modell funktioniert für moderne
    > Softwareentwicklung vorn und hinten nicht.

    Jain. Ich bin kein Fan vom Wasserfall oder V. Allerdings bin ich durchaus der Überzeugung, dass eine gut ausgearbeitete Spec später viel Arbeit oder ein Scheitern sparen kann, unabhängig von der Projektgröße. Natürlich gibt es immer eine Anzahl, meist Vielzahl, von Änderungen später und im Projektverlauf, dass ist klar und die müssen natürlich eingearbeitet werden, aber wenn sich grundsätzliche Anforderungen spät ändern, verfehlen Projekte natürlich ihre Kosten- und Zeitziele unabhängig von der Strategie.

    > Zudem kommt eine
    > Programmiersprache mitnichten nur bei der Implementierung zum Einsatz: bei
    > modernen Programmiersprachen kann man große Teile des Designs mit dem
    > Typsystem ausdrücken.
    >
    > > Die Schwierigkeit beim Schreiben von Tests ist wieder mitnichten die
    > > Sprache. Tests schreibt man überall gleich, das ist praktisch unabhängig
    > > davon, ob das jetzt C++, Java, Python oder .NET ist.
    > Irrtum, Mocking und ähnliches ist in manchen Sprachen wesentlich einfacher
    > als in anderen.

    Das ist ein Punkt, ja. Naturgemäß fällt das in dynamisch oder duck-getypeden Sprachen am einfachsten, weil letzlich gar keine Typprüfung stattfindet. In reflektiven Sprachen ist es auch tendentiell einfacher, als in nicht- oder nur teilweise reflektiven Sprachen wie C++. Also ja, Mocking ist unter C++ manchmal schwieriger als anderswo. Meistens aber kein Problem...

    > > Welche denn? Objekt vergessen zu löschen, weil man 90er Jahre C++
    > schreibt,
    > > wie es nicht mehr gelehrt und nirgendwo empfohlen wird?
    > Schön wär's! De facto wurden Smartpointer doch erst mit C++11 und
    > rvalue-Referenzen vernünftig benutzbar. Mal ganz abgesehen davon, dass man
    > damit auch keine Referenzzyklen aufräumen kann. Wenn ich mir beim
    > Programmieren Gedanken machen muss, ob irgendwo Referenzzyklen auftauchen,
    > läuft irgendwas gewaltig falsch.

    Referenzzyklen sind, wie oben angesprochen, kein Problem, weil es primär GCs (Hallo .Net, Java, Python) betrifft. Und, überraschung, auch bei GCs ist das ein gelöstes Problem.

    > > Gleiche Problematik
    > > übrigens bei C.
    > C hat kein RAII, da kommt man um malloc und free (oder vergleichbares) noch
    > viel weniger herum als in C++.

    Ack.

  14. Re: Die haben halt ein übliches Problem

    Autor: Hello_World 10.09.14 - 16:39

    Dass Du den entsprechenden C++-Code nicht zeigen wolltest oder konntest, belegt dann wohl meine Aussage. Danke für deine Unterstützung.

  15. Re: Die haben halt ein übliches Problem

    Autor: linuxrocks 10.09.14 - 17:07

    Mal ganz ehrlich:
    Die Diskussion: "Meine ♡lingssprache kann irgendwas mit weniger Zeilen machen als deine" ist so 90iger.
    Warum sollte das relevant sein? C++ kann das genau so lösen. Also ist C++ geeignet.
    Die Diskussion war <1999 vielleicht interessant. Aber mittlerweile gibt es Codevervollständigung in den IDEs.

    Zumal wenn es um richtige Projekte geht, so mit Requirements und Dokumentation (nein, keine inline Kommentare, richtige Dokumente) und testen, dann ist die reine Implementationszeit ca. 20 - 30 % der Projektzeit.

    Schreib deine Sachen mit dem was Dir Spaß macht, aber für die allermeisten ernsthaften Projekte spielt die Anzahl der Codezeilen die kleinste Rolle.

    Oder ist das bei Dir anders?

  16. Re: Die haben halt ein übliches Problem

    Autor: Hello_World 10.09.14 - 17:44

    derats schrieb:
    --------------------------------------------------------------------------------
    > Tut mir leid, aber ich jemanden nicht wirklich ernst nehmen, der "C und C++
    > fördern " schreibt. C und C++ haben de-facto nix miteinander zu tun, außer
    > dass eine gewisse Menge von C in C++ enthalten ist. Aber insbesondere
    > Ansätze und Möglichkeiten sind fundamental unterschiedlich.
    Das Maschinenmodell ist bis auf Exceptions komplett gleich. Ebenso verfügen beide Sprachen normalerweise nicht über einen GC, darüber hinaus werden tail calls normalerweise nicht eliminiert. All das hat definitiv einen Einfluss auf den Programmierstil, auch wenn es sich in C++ weniger manifestiert als in C.

    > Interessant, Referenzzyklen sind ausschließlich bei GCs ein Problem, nicht
    > bei Objektbäumen oder shared ptrs.
    Das ist sachlich falsch. Ein Smartpointer, der auf Refcounting setzt, kann keine Zyklen aufräumen. Deswegen braucht man ja auch weak pointer.

    > Natürlich ist Refcounting langsamer,
    > v.a., wenn man für jeden Zugriff oder jeden Scope den Refcount anfässt.
    > Deswegen ist es, wenn man denn shared ptrs der stdlib oder einer anderen
    > Lib nutzt, ratsam Referenzen über einen äußeren Scope zu schachteln. Das
    > ist sicher _und_ schnell.
    Mit anderen Worten, ich muss mir über irgendwelche Low-Level-Details Gedanken machen, über die ich gar nicht nachdenken will, wenn ich auf einem gewissen Abstraktionsniveau programmiere.

    > Außerdem sei natürlich erwähnt, dass du auch in C++ mit einem GC arbeiten
    > kannst
    Bestenfalls mit einem konservativen GC, was dann unter Umständen dazu führt, dass Speicher nicht freigegeben wird, weil irgendetwas auf dem Stack zufällig gerade wie ein Pointer auf den Heap aussieht.

    > Von PCHs scheinst du noch nix gehört zu haben, hm?
    Doch, und sie sind ein Hack, deswegen wird im Rahmen des Clang-Projekts gerade ein Modulsystem entwickelt.

    > Prinzipbedingt kann man Templates nicht extern linken (etwa per DLL), das
    > ist aber eigentlich jedem klar, der sich das fünf Minuten angesehen hat.
    Ja, und das ist ein prinzipieller Nachteil an C++-Templates.

    > Vollständige Spezialisierungen kann man _natürlich_ extern linken, was auch
    > oft gemacht wird, aber eben nicht immer sinnvoll ist.
    > Und natürlich kann man Typprüfungen in Templates machen,
    Nein, kann man nicht. Wenn ich eine Methode auf einer Variablen aufrufe, deren Typ ein Template-Parameter ist, wird der Compiler deswegen nie einen Fehler werfen. Das passiert immer erst, wenn das Template instanziiert wird, und das ist Käse, schon allein weil dann nicht klar ist, wer eigentlich zuständig ist: hat der Benutzer einen Typ übergeben, der nicht passt, oder hat der Autor eines Templates Mist gebaut? Der Compiler kann es nicht wissen und wirft dem Benutzer irgendwelche Fehlermeldungen an den Kopf, die irgendwelche Implementierungsdetails des Templates umfassen, von denen er gar nichts wissen will. Concepts hat man sich ja nicht aus Spaß ausgedacht.

    > das ist nur weit
    > weniger komfortabel in "vanilla" C++, als es mittels Concepts oder externer
    > Bibliotheken ginge, was natürlich nicht schön ist. Aber vielleicht wird das
    > ja mit C++17 was, das wäre sehr schön.
    Oder man verwendet einfach eine Sprache, die solche Probleme nicht hat, Ocaml. Und wenn es denn wirklich auf das letzte Quäntchen Geschwindigkeit ankommt, würde ich mittelfristig eher auf Rust spekulieren als mich mit C++ herumzuärgern.

    > Aber nicht _das_ Problem, wie du es hier darstellst. Dass es vielleicht
    > eher nicht klappt in Brainfuck die neue Steueranwendung zu schreiben... ja,
    > wahrscheinlich. Dass das Projekt scheitert, weil statt verwendet wurde,
    > ist eher unwahrscheinlich. Ob das am Ende in C++ oder Java geschrieben
    > wird, ist eine Detailfrage.
    Nun, da sind wir wohl einfach unterschiedlicher Meinung.

  17. Re: Die haben halt ein übliches Problem

    Autor: Hello_World 10.09.14 - 18:46

    linuxrocks schrieb:
    --------------------------------------------------------------------------------
    > Mal ganz ehrlich:
    > Die Diskussion: "Meine ♡lingssprache kann irgendwas mit weniger
    > Zeilen machen als deine" ist so 90iger.
    > Warum sollte das relevant sein? C++ kann das genau so lösen. Also ist C++
    > geeignet.
    > Die Diskussion war <1999 vielleicht interessant. Aber mittlerweile gibt es
    > Codevervollständigung in den IDEs.
    Mal abgesehen davon, dass eine Codevervollständigung in C++ prinzipiell nicht in 100% der Fälle funktionieren kann (Templates sind turingvollständig, daher weiß man bei Templates nie, welche Methoden ein Objekt am Ende wirklich hat), ist die Schreibarbeit nicht das Problem. Das Problem ist, dass man all diesen Code auch wieder lesen und verstehen muss, wenn man ihn irgendwann verändern will, und da stört Boilerplate-Code enorm. In der Regel ist kurzer Code besser wartbar als langer.

    > Zumal wenn es um richtige Projekte geht, so mit Requirements und
    > Dokumentation (nein, keine inline Kommentare, richtige Dokumente)
    Dokumentation veraltet schnell, was bei Code nie passieren kann: der spiegelt per Definition immer den aktuellen Zustand der Software wieder. Deswegen ist wart- und lesbarer Code so wichtig. Wenn man schon auf umfangreiche Dokumentation in natürlicher Sprache wert legt, halte ich literate programming für einen vielversprechenderen Ansatz.

    > und testen, dann ist die reine Implementationszeit ca. 20 - 30 % der
    > Projektzeit.
    Und deswegen soll lesbarer Code jetzt auf einmal egal sein?

  18. Re: Die haben halt ein übliches Problem

    Autor: Hello_World 10.09.14 - 18:47

    „etabliert“ und „erprobt“ sind die Bullshit-Bingo-Wörter für „wir haben das hier schon immer so gemacht“.

  19. Re: Die haben halt ein übliches Problem

    Autor: Hello_World 10.09.14 - 19:11

    Übrigens bezeichnend, dass immer noch niemand das gezeigte Beispiel in C++ nachgebaut hat – ist euch wohl zu schwierig? Na ja, man kann es z. B. so machen:

    #include <vector>
    template<typename X> std::vector<std::vector<X>> pow(const std::vector<X> &xs) {
    std::vector<std::vector<X>> ret{{}};
    for (const X &x: xs) {
    auto end = ret.end();
    for (const auto &a: ret) {
    ret.push_back(a);
    ret.back().push_back(x);
    }
    }
    return ret;
    }

    Naja, bis auf das unschöne kleine Detail, dass dieses Programm einen subtilen Bug hat. Wer von euch Profis kann mir sagen, wo er sitzt? Tipp: mit einer std::deque statt std::vector ist der Code korrekt.



    1 mal bearbeitet, zuletzt am 10.09.14 19:17 durch Hello_World.

  20. Re: Die haben halt ein übliches Problem

    Autor: pythoneer 10.09.14 - 19:37

    Hello_World schrieb:
    --------------------------------------------------------------------------------
    > Übrigens bezeichnend, dass immer noch niemand das gezeigte Beispiel in C++
    > nachgebaut hat – ist euch wohl zu schwierig?

    Du bist echt der Knaller :D

  1. Thema
  1. 1
  2. 2

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Mitarbeiter:in im Bereich Medienraumausstattung
    STRABAG BRVZ GMBH, Stuttgart, Wien, Spittal/Drau, Molzbichl, Villach (Österreich)
  2. Department Head (m/w/d) IT-Services
    IHP GmbH - Institut für innovative Mikroelektronik, Frankfurt (Oder)
  3. Prozessmanager (m/w/d) Unternehmensentwicklung
    VGH Versicherungen, Hannover
  4. Teamleitung »Support und Bereitstellung« (m/w/d)
    ekom21 - KGRZ Hessen, Darmstadt, Gießen, Kassel, Fulda

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. basierend auf Verkaufszahlen
  2. basierend auf Verkaufszahlen


Haben wir etwas übersehen?

E-Mail an news@golem.de


Chocolatey, Scoop, Winget: Zentralisierte Paketverwaltungen unter Windows
Chocolatey, Scoop, Winget
Zentralisierte Paketverwaltungen unter Windows

Paketverwaltungen bilden unter Linux seit Jahrzehnten das Rückgrat bei der Installation neuer Software. Windows zieht nun nach und integriert ebenfalls zentralisierte Instanzen zur Verwaltung von Softwarepaketen.
Von Erik Bärwaldt

  1. Windows Protected Print Microsoft erklärt Details zu einheitlichem Drucksystem
  2. Microsoft Windows-Nutzer dürfen HP-Smart-Panne selbst ausbügeln
  3. Ungebetener Gast HP-App erscheint unerwartet auf Windows-Systemen

Powerstream-Wechselrichter: Mein Balkonkraftwerk, mein Strom
Powerstream-Wechselrichter
Mein Balkonkraftwerk, mein Strom

Mit dem Powerstream-Wechselrichter hat Ecoflow ein Gerät, das verschiedene Powerstationen des Herstellers als Energiespeicher nutzen kann. Wie gut das funktioniert und wie wirtschaftlich es ist, haben wir ein halbes Jahr lang getestet.
Von Mario Keller

  1. Erleichterungen bei Balkonkraftwerken Bundestag tritt bei Solarpaket auf die Bremse
  2. Juristisches Gutachten Wer haftet bei Schäden durch ein Balkonkraftwerk?
  3. Eigentümer und Mieter Anspruch auf Balkonkraftwerke kommt im Frühjahr 2024

Zbox Pico PI430AJ: Flotter Mini-PC mit Solid-State-Kühlung
Zbox Pico PI430AJ
Flotter Mini-PC mit Solid-State-Kühlung

Die fast lautlosen Kühler von Frore Systems funktionieren gut. Mehr Leistung auf so kleinem Raum ist kaum möglich. Eine ARM-CPU wäre aber spannend.
Ein Test von Martin Böckmann