Hello, Guest the thread was viewed2.8k times and contains 86 replies

last post from daybyter at the

"Modernes" Programmieren vs "Retro" Programmieren

  • Mir fällt auf das viele auf den Frameworks rumhacken. Aber ganz ohne geht es ja nicht oder kann mir einer erklären wie man Windows ohne MFC oder .net programmieren kann?

    Kann mir einer erklären, wie man Windows mit MFC programmieren kann? ;-P


    Wenn ich beruflich mit GUIs in Berührung kam, war das meist Qt, neuerding imgui.

    Muss auch unter Linux tun.

    MFC ist halt was, das gab es damals für Windows und WIMRE auch Mac. Grafischer GUI-Designer, einfach Event-Handler dran hängen und gut ist (meistens). Sowas gab es woanders nicht. Ein fertiges Programmgerüst, mit Standard-Menü und -Toolbar, mit Ausfertigung als Dialog, SDI oder MDI-Anwendung. Deshalb sahen sich viele Programme damals auch sehr ähnlich. Sehr gut für Muskelgedächtnis. Was MFC allerdings im Hintergrund so getrieben hat, ei wei wei.


    Wobei, dass was die Frameworks heutzutage alles unter der Haube verstecken, ist noch viel schlimmer. Dependency Injection sollte ausgemerzt werden, alles, womit man nicht mehr mit dem Debugger von Programmstart bis in die hinterste Ecke am Stück durchsteppen kann, ist Müll. Ist auch nur ein glorifiziertes Singleton mit Service/Reflection-Container. Ich rede mich schon wieder in Rage :)


    Ich schleppe seit Anbeginn der Zeiten ein MFC-Zeichenprogramm mit, da bastle ich ab und an nochmal Anpassungen rein, wenn sich irgendjemand mal wieder ein neues Grafikformat aus der Birne quetscht (oder so wie neuerdings Teams meint, ein Bild im Clipboard habe ein HTML-Blob mit Base64-Encodierung zu sein). Da merkt man schon, dass es in die Jahre gekommen ist. Inzwischen gibt es deutlich Besseres (Win-Forms zum Beispiel!), aber auch noch viel schlechteres (so ziemlich alles mit Web)

  • Mir fällt auf das viele auf den Frameworks rumhacken. Aber ganz ohne geht es ja nicht oder kann mir einer erklären wie man Windows ohne MFC oder .net programmieren kann?

    Qt oder andere Frameworks für eine nette GUI finde ich gar nicht so schlecht. Bei PHP & Co. finde ich das dann eher nervig. Wozu vogonische Lyrik lernen, wenn man es auch direkt mit PHP machen kann ? - Und man hat eine Fehlerquelle bei Updates im Untergrund weniger. Mag aber auch an der Größe der Projekte liegen.

  • Bei PHP

    :X


    Ich hatte bei einem Onlinespiel gefragt wie ein bestimmter Code zu verstehen ist. Antwort "Das ist der Pythagoras." 8|

    Das war für mich absolut unlesbar. Daher hatte ich ToHellWithPHP.gif erfunden. :D

  • Dependency Injection sollte ausgemerzt werden, alles, womit man nicht mehr mit dem Debugger von Programmstart bis in die hinterste Ecke am Stück durchsteppen kann, ist Müll. Ist auch nur ein glorifiziertes Singleton mit Service/Reflection-Container. Ich rede mich schon wieder in Rage :)

    Wenn ich sowas lese ("ausmerzen"), dann denke ich immer, dass mir jemand vorschreiben will, wie ich zu programmieren habe.

    Ist das der richtige Weg? Andere zu bevormunden?`


    Es gibt Frameworks, wo Dependency Injection extrem hilfreich ist. Zum Beispiel wenn man unter Xamarin (inzwischen ersetzt durch MAUI) Programme für Android und iOS schreibt und über Dependency Injection die passenden Funktionen für das jeweile OS festlegt uns sich dann im Rest des Programms nicht mehr darum kümmern muss, für welches OS das jetzt gilt.

  • die Dinge sehr unnötig kompliziert angegangen

    Ich brauchte nur einen Stack, wo jeder Eintrag aus zwei Elementen besteht. Also nix Kompliziertes eigentlich, sondern Routine im Programmiereralltag. Aber in Perl ziemlich kompliziert.

    Ja gut, da braucht man halt Referenzen:

    An der Stelle ist Python einfacher, zugegeben. Aber wenn man sich ein bißchen daran gewöhnt hat, wie man das in Perl macht (ich glaube, das ist überhaupt erst ab Perl 5 möglich geworden), dann geht es einem eigentlich auch recht schnell von der Hand.

  • Ja gut, da braucht man halt Referenzen:

    Das habe ich dann auch in einem Perl-Buch gelesen. Und wenn Referenzen ins Spiel kommen, ist man ja nicht mehr so weit von Zeigern entfernt. Ok, Zeiger sind schon fehleranfälliger. Aber C wurde ja ursprünglich für die (portable) Systemprogrammierung erfunden, wo man um das Hantieren mit Adressen nicht herum kommt.


    Auf jeden Fall ruht das Perl-Projekt seitdem. Es sollte ein Prototyp für einen Assembler-Precompiler werden.

  • Auf jeden Fall ruht das Perl-Projekt seitdem. Es sollte ein Prototyp für einen Assembler-Precompiler werden.

    Könntest es ja nochmal in Python versuchen. Macht wie gesagt Vieles nochmal einfacher. Sehr viele Leute sind sehr glücklich damit.

    Code
    1. #!/usr/bin/python
    2. # coding: utf-8
    3. a = [[1, 2],
    4.     [3, 4],
    5.      [5, 6]]
    6. b = a.pop()
    7. for i in b:
    8.     print(i)
  • Ja gut, da braucht man halt Referenzen:

    Das habe ich dann auch in einem Perl-Buch gelesen. Und wenn Referenzen ins Spiel kommen, ist man ja nicht mehr so weit von Zeigern entfernt. Ok, Zeiger sind schon fehleranfälliger. Aber C wurde ja ursprünglich für die (portable) Systemprogrammierung erfunden, wo man um das Hantieren mit Adressen nicht herum kommt.


    Auf jeden Fall ruht das Perl-Projekt seitdem. Es sollte ein Prototyp für einen Assembler-Precompiler werden.

    Für solche Sachen würd ich eher Antlr nehmen, oder etwas ähnliches.

  • Wobei, dass was die Frameworks heutzutage alles unter der Haube verstecken, ist noch viel schlimmer. Dependency Injection sollte ausgemerzt werden, alles, womit man nicht mehr mit dem Debugger von Programmstart bis in die hinterste Ecke am Stück durchsteppen kann, ist Müll. Ist auch nur ein glorifiziertes Singleton mit Service/Reflection-Container. Ich rede mich schon wieder in Rage

    Dann wird dir dieses Buch nicht gefallen, hier wird viel mit loser Kopplung gearbeitet und die klassischen Vererbung wird damit aufgebrochen. Ich selbst hatte noch nie Probleme das zu debuggen, hast halt oft Objekte in Objekten anstelle von Objekt erbt vom anderen Objekt.

    https://www.oreilly.com/librar…are-design/9781098113155/


  • Wenn ich schon Design Pattern lese, dann ist es vorbei :) Die Go4 haben genug Dödel rangezogen, die unbedarft mit Design Patterns um sich werfen. Es ist schick, wenn man einen Namen für übliche Vorgehen hat, aber man sollte bitte nicht anfangen, mit Gewalt alles mit diesen Dingern aufzubauen.


    Ich habe mit DI nur schlechte Erfahrungen gemacht, das wird einem ja teilweise von Frameworks aufgezwungen. Alles compiliert schön, und zur Laufzeit jammert dann das Programm, dass es keine passende Klasse für ein Interface findet. Und dann kann man sich einen abbrechen um rauszufummeln, was genau ihm fehlt.


    Hauptsache, man hat nicht Interface = new ObjektDasInterfaceUmsetzt() irgendwo geschrieben, sondern das irgendwo in drölfzig Helferklassen versteckt. Man könnte ja sonst sehen, welche Klasse man jetzt benutzt.

    Was relativ angenehm ist, dass man Interfaces als Members oder im Constructor angeben kann, und das DI-Teil selbst austüftelt, in welcher Reihenfolge man die Objekte bauen muss, damit jedes ein gültiges Interface bekommt. Aber IMHO lohnt sich das wegen der anderen Kopfschmerzen nicht. Das ist zu 99% YAGNI. Wie oft hast du wirklich mal eine andere Klasse einsetzen lassen?


    Die gleiche Art Leuten baut offenbar die Standard-Regeln für statische Code-Analyse-Tools wie SonarQube. 90% Bullshit-Regeln (Die Funktion ist zu komplex (>57) ! Da sind mehr als zwei IFs verschachtelt! Das sieht wie eine Abkürzung aus, das muss man in Großbuchstaben schreiben!). Da gehen echte Warnmeldungen im Blödsinn unter.

  • Hab meine 15 Jahre als Web-Entwickler hinter mir. Hab hingeworfen. Die letzten Jahre nur noch Kartenhäuser gebaut. Frustrierend. Massen an dependencies (und dependencies von dependencies) - keine Chance überhaupt noch durchzublicken. Keine Ahnung was der code überhaupt *genau* machte. Als ich Anfing war das der Super-GAU - ein Programmierer muss seinen Code kennen / verstehen. Aber irgendwann schlich sich das irgendwie als "normal" ein. (Und wir dachten mal, die jQuery lib mit 300kb einzubinden sei krasser Sch…)


    Es wurde auch immer weniger tatsächlich code geschrieben. Zu beschäftigt den Tool-Stack zu pflegen, Code-Reviews zu machen und sonstiges.

    Und dann ständig kommt das angebliche "next big thing" um die Ecke und dein gesamtes Wissen veraltet. War stark in AngularJS v.1 damals investiert, dann kommt v2.0 und macht praktisch das ganze Wissen obsolet.


    Was mich auch sehr anfing zu stören, war das jeder irgendwann begann nur noch nach „Lösungen“ zu suchen. Früher saßen wir zusammen und haben im Team über ein Problem gesprochen (und dabei dann oft entdeckt, wie man es lösen könnte). Aber mit der Zeit fingen wir an, nur noch von Lösung zu Lösung zu hüpfen, ohne sich die Zeit zu nehmen, Probleme wirklich zu verstehen. Da wurden dann nur noch Lösungen präsentiert. Ist ja auch verlockend und macht das Leben so viel einfacher! Man springt einfach auf StackOverflow, wo Lösungen auf eine Art angeboten werden, bei denen man nicht über das Problem nachzudenken braucht. („Wie kann ich …?“ - „Nutze Function X in framework Y dafür“). Das führt aber zur effektiven Verringerung von Wissen, nicht der Vermehrung. Ich finde es da keine Überraschung, dass wir heute in der Tech-Welt leben, in der wir leben.

  • Wenn ich schon Design Pattern lese, dann ist es vorbei :) Die Go4 haben genug Dödel rangezogen, die unbedarft mit Design Patterns um sich werfen. Es ist schick, wenn man einen Namen für übliche Vorgehen hat, aber man sollte bitte nicht anfangen, mit Gewalt alles mit diesen Dingern aufzubauen.

    Haha, ja das geht mir aber genauso. Ich nutze zwar in meinen Backend auch Dependency Injection allerdings ganz wenig und OOP ist auch sehr minimal. Ich habe einen Kollegen der ballert alles mit Design Pattern voll, egal ob es Sinn macht oder nicht. Da durchzublicken kostet extrem viel Zeit, weil ich dem Programmfluss nur schlecht folgen kann und jedes Mal, wenn ich das Projekt länger nicht angefasst habe, geht die Reise von vorne los.

    Hab meine 15 Jahre als Web-Entwickler hinter mir. Hab hingeworfen. Die letzten Jahre nur noch Kartenhäuser gebaut. Frustrierend.

    Ja, das ist alles ein Haufen Miste mittlerweile. Ich mache es weil ich dafür bezahlt werde, privat rühre ich den Kram nicht an. Ich bin auch seit der Jahrtausendwende beruflich da mit dabei und habe noch kein Projekt gesehen was nach Lehrbuch entwickelt wurde, vielleicht schaffe ich da mal eins bis zur Rente^^


    Mich wundert überhaupt, dass soviel Software überhaupt läuft ohne alle 3 Sekunden Probleme zu machen^^


    Das einzig schöne an dem Job, man muss die Wohnung so gut wie nie verlassen.

  • Hauptsache, man hat nicht Interface = new ObjektDasInterfaceUmsetzt() irgendwo geschrieben, sondern das irgendwo in drölfzig Helferklassen versteckt.

    Und wenn das nicht fix? Und sich womöglich doch erst zur Laufzeit entscheidet. Man kann doch nicht alles statisch vorgeben.

    Arbeitest du dann mit Class-Factories (auch wieder so ein Design Pattern ;)) oder mit altmodischen case-Kaskaden.

    Manchmal kommen die Klassen aus einem ganzen Projekt oder aus einer Library. Sowas will man doch nicht fest koppeln.


    Und von anonymen Methode und Lambda-Ausdrücken hältst du dann sicher auch nicht. Du scheinst irgendwie gegen alles zu sein, was moderne Programmierung ausmacht. :gruebel

  • Hauptsache, man hat nicht Interface = new ObjektDasInterfaceUmsetzt() irgendwo geschrieben, sondern das irgendwo in drölfzig Helferklassen versteckt.

    Und wenn das nicht fix? Und sich womöglich doch erst zur Laufzeit entscheidet. Man kann doch nicht alles statisch vorgeben.

    Arbeitest du dann mit Class-Factories (auch wieder so ein Design Pattern ;)) oder mit altmodischen case-Kaskaden.


    Und von anonymen Methode und Lambda-Ausdrücken hältst du dann sicher auch nicht. Du scheinst irgendwie gegen alles zu sein, was moderne Programmierung ausmacht. :gruebel

    Ich habe noch kaum ein Projekt getroffen, wo man dieses Dependency-Zeug wirklich brauchte. In fast allen Fällen war es genau eine Klasse die es gab, und die hat man per Interface verwendet. Dafür brauche ich doch so ein Verstecken nicht?


    Anonyme Methoden und Lambda-Ausdrücke sind nett für Delegates, aber etwas schlecht zu lesen IMHO.


    Je komplexer etwas ist, umso schlechter ist es für Wartbarkeit. Wenn man nach einem Monat den Code nicht mehr versteht, dann ist das nicht wirklich gut.



    Edit: Gut möglich, dass ich etwas konservativer unterwegs bin beim Programmieren :)

    IMHO müssen sich neue Methoden erst einmal beweisen. Leider sehe ich immer wieder einen Hang zum Hype Driven Development, da gleitet man ganz schnell ab, und versucht die neue Technik überall unterzubringen.

    Vielleicht bin ich da auch gebranntes Kind. Ich habe einige Projekte unter meinen Fittichen, wo irgend jemand eine neue Technik halbherzig ausprobiert, damit ein neues LinkedIn-Tag gewonnen und sich dann verdrückt hat. Und ich habe dann die Projekte mit den tollsten Varianten hier und muss die pflegen.


    Breathe Paper Bag GIFs - Find & Share on GIPHY

  • Wenn ich schon Design Pattern lese, dann ist es vorbei :) Die Go4 haben genug Dödel rangezogen, die unbedarft mit Design Patterns um sich werfen. Es ist schick, wenn man einen Namen für übliche Vorgehen hat, aber man sollte bitte nicht anfangen, mit Gewalt alles mit diesen Dingern aufzubauen.

    Wir hatten mal einen Kollegen in der Probezeit dem habe ich eine realtiv einfache Aufgabe gegeben unser Testframework zu refactoren. Er hat alle sumgeschrieben,mit statischen Klassen versehen und das ganze so kompliziert gemacht dass wirklich KEINER der Kollegen verstanden hat wie das Teil funktioniert, gar nicht zu rden davon wenn man das Teil erweitern muss in der Zukunft. Ich bin sicher auf der Uni hätte er ein dickes Plus mit Sternchen bekommen, aber wir haben das ganez verworfen und mit meinem Konzept gemacht, so wie ich das eigentlich geplant hatte. Flexibel erweiterbar, leicht zu verstehen und tut alles was es soll.

    Na, ja. Der Kollege hat die Probezeit nicht überstanden. Nicht deswegen, aber wir waren froh als er weg war.

  • Ich habe noch kaum ein Projekt getroffen, wo man dieses Dependency-Zeug wirklich brauchte. In fast allen Fällen war es genau eine Klasse die es gab, und die hat man per Interface verwendet. Dafür brauche ich doch so ein Verstecken nicht?

    Ich hatte letztes Jahr ein Projekt mit C#. Der Kollege der das mit mir gemacht hat, kannte jedes Framework in und auswendig und hat wirklich ALLES mit DI gemacht. Ich habe Monate gebraucht um nur die einfachsten Änderungen machen zu können. Dafür war der Code für das Gesamtprojekt relativ klein, nur hat ihn keiner verstanden (nicht nur ich). Wir haben das Projekt später an eine andere Abteilung abgegeben, worüber ich sehr froh war. Die Abteilung hat dann das Projekt komplett neu in Java geschrieben. Tja. Die Frameworks haben zwar viel Arbeit gespart, aber wenn man es über die ganze Zeit betrachtet dann doch nicht, weil alles neu entwickelt wurde.