Was ist denn eine "hardwarenahe Programmiersprache"?
Sowas gibts nicht... Es gibt Programmiersprachen, die in verschiedenen "Klassen" eingeteilt sind. Die erste Stufe sind "Maschinensprachen" -> dort schreibst du direkt in Maschinencode, ohne Umschweife oder sonstiges. Das Ganze ist dabei 1:1 auf die Maschine/den Prozessor zugeschnitten und läuft normal auch nur darauf bzw. auf dazu kompatibler Hardware.
Darüber kommen maschienorientierte/symbolische Sprachen oder neudeutsch auch Assemblersprachen genannt. Hier werden die Zahlenkolonnen der Maschinensprachen durch besser lesbare symbolische Ausdrücke ersetzt. Der Nachteil dabei ist, es bleibt idR bei einer Hardwarebindung. Assemblercode für x86 kombatible Prozessoren wird per se nicht auf einer NV oder AMD GPU laufen.
Die dritte Stufe sind problemorientierte Sprachen oder auch Hochsprachen. -> das ist das, was man idR heute nutzt. Sprachen wie C(++), C#, VB und auch Java usw. Die dritte Stufe wird dabei sogar nochmal unterteilt in Unterstufen, wobei die Übergänge oftmals fließend sind. Der wohl aktuell höchste Ansatz sind die objektorientierten Sprachen.
Wo findet sich in dieser Übersicht nun eine "hardwarenahe Programmiersprache"? -> das müsste Ebene 1 oder 2 sein. Das nutzt allerdings heute fast keiner mehr und hat auch Gründe. Programmcode ist heute extremst komplex, da fließen viele tausend Codezeilen rein. Das ganze hardwarenah in Assembler oder direkt in Maschinensprache zu schreiben wäre overkill ohne Ende. Der Zeitaufwand wäre exorbitant und das Ergebnis wäre bestenfalls ernüchternd. Denn das Problem ist, heutige Compiler erzeugen idR annähernd "perfekten" Maschinencode. Man gibt ihm einfach eine Hochsprache zu füttern und es kommt sauberer Maschiencode hinten raus. Und nicht nur das, der heutige Compiler ist oftmals auch in der Lage, Optimierungen vorzunehmen, für die der Programmierer, welcher in Assembler oder Maschinencode schreiben würde, extrem viel Aufwand für die Implementierung haben würde. Bspw. lassen sich Zählschleifen ala "for" fluffig leicht Multithreaded ausführen. -> hier kann der Compiler ansetzen und einfach diese Optimierung durchführen. Schreib mal ein Multithreaded Tool in Assembler -> viel Spaß dabei. Warscheinlich bekommen die meisten Programmierer heute nichtmal "Hello World" via Assembler, geschweige denn direkt in Maschinencode auf den Schirm gezaubert. Da ist nix mit "cout" oder ähnlichem, das wird schön direkt auf/in den Framebuffer geschoben und dann der entsprechende Interupt angetriggert, vorher noch die Register laden usw. -> was du in einer Hochsprache mit nichtmal 50 Zeichen Text hinbekommst, würde in Assembler mehrere Zeilen mit wild wirkenden Befehlen bedeuten. Von Maschinencode ganze zuschweigen. Und das für eine simple Stringausgabe auf dem Schirm!
Du unterschlägst dabei aber eine ganze Menge...
Der wohl wichtigste Punkt ist, Software ist heute einfach drastisch komplexer als noch vor Jahren... Früher haben die Programmierer da innerhalb von ein paar Wochen/Monaten fertige Software entwickelt, einfach weil die Geschichte derart wenig Komplex war, dass sowas überhaupt erstmal möglich war. Was man brauchte war fundiertes Wissen über die Hardware und los gehts. Heute brauchst du kein direktes Wissen mehr über die Hardware, sondern du musst dich in der Hochsprache auskennen. Den Rest übernimmt das System für dich. Das ist ein himmelweiter Unterschied zu damals.
Auch sind heute Bugs und Fehler eher Logikprobleme in der Programmbeschreibung des Hochsprachencodes. Früher in Maschinencode/Assemblercode waren Fehler keine Logikprobleme, sondern schlicht Fehler. Die Compiler machen heute einfach nur dass, was man ihnen sagt. Wenn die Logik dahinter falsch ist, kann der Code ja nix für, der hinten raus kommt. Der PC rechnet nur das, was man ihm sagt und macht dabei möglichst auch keine Fehler
Ebenso hat sich die Programmierkultur über die Jahrzente geändert. Früher, zu Zeiten, wo die Heimcomputer so langsam Fahrt aufnahmen, haben sich die Programmierer durch Wissen über die Hardware gewisses KnowHow angeeignet. Wenn man weis wie die Maschine tickt, kann man auch die Maschine an gewissen Punkten austricksen. Ich sag nur Stichwort A20 Gate. Da kommen dann Leute und bauen sich über einen "Umweg" eine Funktion, die so nicht hätte sein sollen. Wo gibt es heute sowas noch?
Es hindert sich doch niemand, in Assembler oder Maschinencode zu schreiben. Ehrlich gesagt verstehe ich das Problem nicht...
Mir scheint eher, dass du da einem kleinen Verständnisproblem unterliegst. Nicht die Hardwarenähe (oder besser gesagt "ferne" in dem Fall) ist das Problem, sondern das Problem ist die Kompatibilität. Software ohne Hochsprachen wären schlicht nicht kompatibel zu verschiedenen Hardwareeinheiten. Wie soll das bspw. in Games funktionieren? Da kommt NV Code, AMD Code und Intel Code für die GPUs raus. -> das unter einen Hut zu bringen heist entweder 3x die Arbeit zu erledigen und damit auch 3x in Probleme zu laufen oder man nutzt eine Hochsprache mit entsprechenden Schnittstellen, welche alle Hersteller supporten und damit auch grundsätzlich eine Lauffähigkeit geschaffen ist.
Das ganze Marketing BlaBla von wegen Low Level Programmierung im GPU Bereich ist doch nur Sülz im Vergleich. Das ist bestenfalls "lower level" aber nicht "low level". Man kann sich von der Hardwarenähe einfach nix kaufen. Wichtig ist, dass die Implementierung der Funktionen so sauber funktioniert, dass man die gewünschen Thematiken damit abdecken kann. Low Level in Maschinencode wird heute nur noch das allerwenigste erzeugt, da der Code idR ineffizient ist. Zumindest ineffizienter als ein anständiger Compiler es fabrizieren würde, vor allem dann, wenn die Problemstellungen komplex(er) sind...
Was das Thema Geld/Zeit angeht, da stimme ich dir grundsätzlich aber zu. Programmierung in der heutigen Zeit darf idR nix kosten. Aber Programmierer sind teuer. Entsprechend kommt es hier zu einem Zielkonflikt. Anders als noch vor Jahrzenten, wo eben eine einzige Person in der Lage war, ein entsprechendes Werk abzuliefern binnen ein paar Wochen, benötigt es heute viele Programmierer um erstmal das Grundgerüst zu schaffen. Dazu kommen Leute für die Grafik und Leute für das Spiel selbst, Leveldesigner, Sprecher, usw. usf. In der Zeit, wo die Softwareentwicklung läuft, verdient man aber nix. Also muss man in Vorkasse gehen -> das geht solange gut, wie Geld da ist. Irgendwann muss man aber abliefern. Ob fertig und bis ins letzte Detail fehlerfrei oder nicht. Auch kostet Fehlerbeseitigung im Nachgang Geld, welches nicht direkt honoriert wird. Bestenfalls indirekt durch höhere Verkaufszahlen. Klappt aber auch nur gewisse Zeit nach dem Release, da einfach nach alter Software idR kein Hahn mehr kräht.
