Hallo Besucher, der Thread wurde 7,8k mal aufgerufen und enthält 91 Antworten

letzter Beitrag von Goodwell am

"Modernes" Programmieren vs "Retro" Programmieren

    Zitat von berni

    Ich finde das total interessant zu lesen, wie es euch allen so gegangen ist. Und dass ich nicht der einzige "Verrückte" bin, der diesem modischen Krempel skeptisch gegenüber steht.

    Ich hab mir schon viele Gedanken darüber gemacht, warum denn das so ist.


    Meine Folgerung:

    es ist für jeden Programmierer schwierig, sich in bestehenden Code einzuarbeiten.

    Oder böse formuliert: es ist befriedigender, sich selber seine Strukturen zu schaffen.

    Wenn es dann auch noch eine neuere Sprache gibt, die man uU in der Ausbildung gelernt hat, dann ist es leicht, Code und Technologie zu verteufeln.

    Und von vorne zu beginnen.

    Jeder Programmierer nimmt dann aber ohnehin wieder seine eigenen Abkürzungen, die der nächste Programmierer wiederum nicht auf den ersten Blick versteht.

    Woran keiner denkt: was passiert mit meinem Code, wenn ich an diesem Projekt kein Interesse mehr habe? Oder zum CEO werde?

    Und somit geht das Spiel von vorne los.


    Die Lösung (für große Teams, oder Firmen): einheitliche Code-Strukturen schaffen und ordentliche Einschulungsphasen für jene, die neu zu den Teams dazukommen, damit die nicht wieder ein neues Fass aufmachen sobald keiner hinsieht.


    Und Frameworks: die sind dann spitze, wenn man zu 100% versteht, was sie machen.

    Die Frameworks bewerben sich aber eigentlich damit, dass man nicht verstehen muss, was sie machen.

    Und wenn ich verstehen soll was ein Framework macht, dann denkt jeder, kann ichs eh gleich selber machen.


    Das einzige, was mir bei Commodore Basic wirklich wirklich wirklich fehlt, also so richtig wirklich, das ist die Isolation von Variablen.

    Wenns was gäbe, damit man sich nicht ständig selber versehentlich die Variable von letzter Woche überschreibt, dann wär ich glücklich :-)

    Zitat von next_i

    Mit bash und C konnte ich weniger anfangen. Perl und Python sind immer noch meine Favoriten. Aus dieser Perspektive hab' ich dann nochmal auf Sinclair BASIC zurückgeschaut. Und darauf, daß man die 8-Bit-Computer praktisch immer noch entweder in BASIC oder in Assembler programmieren sollte.

    Perl ist doch auch nur C in auch für den Programmierer kryptisch.


    Zitat von next_i

    Wenn man vor allem Python kennt, werden einem die Schwächen von BASIC so richtig klar. Spaghetti-Code, keine Funktionen, Zeilennummern, globale Variablen. Nicht schön.

    Alles ist in der Hinsicht besser als Basic V2.


    Zitat von next_i

    Programmieren unter Linux wirkte zuerst sehr fremdartig, mit "vim", "bash", "gcc" und Makefiles, aber letztlich war es doch möglich, die Verbindung zu den früheren Konstrukten herzustellen.

    Die Lernkurve ist zwar ziemlich steil, aber wer den Berg erklimmt, hat für immer den Durchblick.


    Zitat von next_i

    Und im Vergleich zeigte sich, daß moderne Sprachen und Interpreter unter Linux doch sehr viel komfortabler und leistungsfähiger sind als das BASIC auf den 8-Bit-Rechnern

    Was aber keine große Kunst ist.

    Zitat von next_i

    Als Kind bzw. Jugendlicher hab' ich ein bißchen in BASIC programmiert. Auf dem Spectrum, und später in Amiga BASIC (von der "Extras"-Diskette"). War aber alles nicht so dolle. Von dem Schritt zu Assembler hab' ich oft "geträumt", aber das hat nie geklappt.

    Meine ersten Schritte waren auch in BASIC. Logo, das hat wohl jeder gemacht weil es einfach da war. :D Ich fand es totalbeeindruckend wenn ich so einen Crackerintro gesehen habe z.B. von GCS mit der Deutschlandfahne über den kompletten Bildschirm mit RasterIRQ. Das habe ich natürlich gar nicht verstanden was das genau sein soll, fand es nur beeindruckend. Und einer hat mir dann erklärt das sowas nur in Assembler geht und Mega kompliziert ist. Das Thema war dann für mich erstmal abgeschlossen. Als ich dann versucht habe ein Demo iin BASIC zu schreiben habe ich das schnell wieder aufgegeben. 8 Sprites am Bildschirm bwegen und sonst nichts, und das war schon quälend langsam.

    Dann habe ch mal in einem Databecker Buch ein paar Zeilen Assembler gesehen und eine genaue Beschreibung für die Befehle (Nein es war nicht ein Buch über Asembler lernen sondern was anderes und das war nur ein kleines Beispiel in dem Buch). Jedenfalls habe ich dann damit rumgespielt und fand das dann gar nicht SO schwer wie jeder behauptet hat. Danach habe ich dann nur noch in Assembler programmiert.

    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?

    Zitat von oobdoo

    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?

    Ganz ohne gehts nicht stimmt.


    Und die von dir genannten gibts seit Ewigkeiten und sind stabil.
    Ich persönlich verurteile eher die flüchtige Konsistenz von Frameworks, weniger das Prinzip an sich.

    Zitat von oobdoo
    Zitat von Int42
    Zitat von oobdoo

    man Windows ohne MFC

    WinAPI

    Hast Du auch damit programmiert? Ich nicht, aber ich vermute das es eine Freude ist.

    Ja, habe ich schon, aber nur privat. In der Firma wird noch Software verkauft die auf WinAPI basiert, da ist aber mit der Zeit ein selbstgemachtes Framework drum rum gekommen. Klar, ohne Frameworks ist heute kaum mehr ein Blumentopf zu gewinnen. Bei uns geht aber alles Richtung Web, die klassischen Desktop Apps, in der alten Form, haben keine Zukunft mehr bei uns. Allerdings laufen die Folgeversionen natürlich trotzdem noch auf dem Desktop, was dann aber nicht viel mehr ist als ein Browserfenster, was man aber so nicht sofort erkennt.

    Zitat von Goodwell

    Ich persönlich verurteile eher die flüchtige Konsistenz von Frameworks, weniger das Prinzip an sich.

    Oh mir fallen direkt mehrere althergebrachte Frameworks ein, die einfach eher Schrott sind und trotzdem ständig benutzt werden.


    Z.B. so gut wie alle ORMs (sqlalchemy und Konsorten). Da ist das Konzept schon kaputt: Das Versprechen ist, von einer konkreten Datenbank zu abstrahieren (braucht kaum jemand und funktioniert auch nicht: sobald man was Nichttriviales macht, braucht man eigentlich immer Datenbank-spezifischen Krams); ein anderes Versprechen ist, den Zugriff auf die Daten zu vereinfachen (aber trotzdem muss man ständig irgendwelche Wrapper für besondere Datentypen schreiben); einfache Dinge bleiben einfach, ja, aber komplexe Dinge werden unmöglich (eine Tabelle ohne Primary Key? Nicht wirklich möglich, will man aber z.B. bei richtig großen Tabellen haben, weil z.B. Postgres bei Primary Keys immer einen btree-Index anlegen will - der bei z.B. langen Strings als PK aber riesig wird); und das ganze Framework erzieht den Programmierer dazu, "faul" zu programmieren (statt nur die Daten zu holen, die man braucht, immer wegen ORM eben deutlich mehr; selten wirklich gute und schnelle Queries schreiben, stattdessen Objekte en masse holen und die dann von Hand filtern). Und da die ORM auch gleich auch Dinge wie Connection Pools und Transaktionen versteckt, weiß man an der Stelle auch nie so genau, was eigentlich los ist. Und die Doku der ORMs liest sich auch genau so: "Um das Äquivalent von (einfaches SQL-Statement) zu machen, müssen Sie lediglich folgende 30 Zeilen Code schreiben...". :(


    Oder so gut wie alles, wo "Apache" dransteht. Das ist fast immer schwerfälliges overengineertes Zeugs mit furchtbarer veralteter verschwurbelter Dokumentation und starkem Geruch von Design by Committee.


    Dann gibt es noch die Sachen, die den Alterstod bzw. an der Library-Variante von Enshittification sterben. React zum Beispiel. Hätte man umbenennen müssen, als sie mit Hooks kamen, weil es danach einfach was anderes war als vorher und dadurch alle externe Doku und Stackoverflow etc. unbrauchbar wurden. Und jetzt ist React halbtot, weil alle Entwickler von Next.js abgeworben wurden, und das ist unbenutzbar, weil der Inhaber einen Scheiß auf Selfhosting gibt und an allen Ecken und Enden zu seinem Hosting drängelt (mit Server Side Rendering natürlich, auch wenn keiner so wirklich weiß, was das bringen soll außer Kosten).

    Zitat von sparhawk

    Ich fand es totalbeeindruckend wenn ich so einen Crackerintro gesehen habe z.B. von GCS mit der Deutschlandfahne über den kompletten Bildschirm mit RasterIRQ. Das habe ich natürlich gar nicht verstanden was das genau sein soll, fand es nur beeindruckend. Und einer hat mir dann erklärt das sowas nur in Assembler geht und Mega kompliziert ist.

    Warum macht die seit Windows 3.1 gefühlt eigentlich kaum noch jemand? Es gab nochmal den "Geiss Screensaver", den fand ich auch sehr beeindruckend, und das war in den 90ern. Heute dürfte technisch doch noch viel mehr gehen.

    Aber wenn ich heute mal irgendwo eine Demo sehe, dann ist es für einen Retro-Computer wie Spectrum Next oder Agon Light.

    Ne fette Demo für meinen PC oder zumindest für den RaspPi wäre doch aber auch cool.

    Bei "Demo" denke ich immer noch an die Robot-Demo auf dem Atari 8-Bit ("ATARIDMO.OBJ"). Kann doch nicht sein, da müßte doch noch was danach gekommen sein.

    Zitat von 1570

    (eine Tabelle ohne Primary Key? Nicht wirklich möglich, will man aber z.B. bei richtig großen Tabellen haben, weil z.B. Postgres bei Primary Keys immer einen btree-Index anlegen will - der bei z.B. langen Strings als PK aber riesig wird)

    Ich lege für jede Tabelle immer eine Integer-Spalte mit dem namen "id" als Primärschlüssel an.

    Zitat von ogd

    Perl ist doch auch nur C in auch für den Programmierer kryptisch.

    lol, Vorurteile ... Perl hat halt eingebaute dynamische Datentypen wie Listen und Hashs, automatische Speicherverwaltung und eine eingebaute leistungsfähige RegEx-Engine. Man braucht sich auch nicht mit "Zeigern" oder "Zeigern auf Strukturen" rumzuärgern. Das macht die Dinge um Längen einfacher. Aber natürlich auch langsamer.

    Zitat von ogd

    Ich lege für jede Tabelle immer eine Integer-Spalte mit dem namen "id" als Primärschlüssel an.

    Dadurch würde der Kram hier gleich mal ein paar dutzend GB mehr auf Platte belegen und man einen nutzlosen Index (der auch bei Inserts aktualisiert werden will) mitziehen. Glaub mir, in manchen Projekten macht das einen Unterschied. Und ich will das auch nicht machen (müssen), nur weil irgendeine ranzige ORM sonst unglücklich ist.

    Zitat von oobdoo

    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.

    Zitat von ogd

    Ich brauchte mal für ein Perl-Projekt ein "Stack aus Strukturen". Da hörte es mit der Einfachheit auf.

    Waas? Da ist aber jemand die Dinge sehr unnötig kompliziert angegangen.

    Sowas kann passieren, wenn jemand Strukturen aus einer anderen Sprache unbedingt in das Programm übertragen will, also sozusagen etwas wortwörtlich übersetzen will, ohne auf die Eigenarten der Zielsprache einzugehen. Der Normalfall ist das aber nicht.

    Zitat von RexRetro
    Zitat von oobdoo

    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

    MFC ist so eine dünne Abstraktion dass man eigentlich genausogut mit Win32 arbeiten kann. :D Qt ist recht gut. Ich verwende meistens wxWidgets.