Diskussion:Programmiersprache
NPOV im Unterabschnitt Panorama
Dort steht Esoterische Programmiersprachen sind experimentelle Sprachen mit teilweise interessanten Konzepten., was ja recht eindeutig eine persönliche Bewertung ist. Ich habe allerdings zu wenig Ahnung von Programmiersprachen, um das durch einen besseren Satz zu ersetzen. --קеלея ihm sein Knie 15:36, 3. Dez. 2016 (CET)
- Der weltweit eingebürgerte selbstironische Ausdruck „Esoterische Programmiersprachen“ hat schon viele Laien in die Irre geführt und an Fackeltänze bei Vollmond um einen Mac glauben lasen. Ist kein POV. Lies wenigstens die Einleitung des verlinkten Artikels. VG --PerfektesChaos 15:50, 3. Dez. 2016 (CET)
- Haha, ich glaube Du hast mich falsch verstanden, lieber Benutzer:PerfektesChaos, obwohl Fackeltänze um einen Mac eine lustige Vorstellung sind. Ich meinte nicht "esoterisch" mit POV, sondern teilweise interessante Konzepte. Warum sind diese Konzepte nur teilweise interessant und nicht uninteressant oder hochinteressant? Außerdem klingt "teilweise interessant" wie eine nette Umschreibung für "größtenteils dämlich". --קеלея ihm sein Knie 12:31, 9. Dez. 2016 (CET)
- Hm, ja, das ist unbelegt wertend.
- Hab's mal anders formuliert.
- --arilou (Diskussion) 13:23, 9. Dez. 2016 (CET)
- War wohl nicht wertend gemeint gewesen; tatsächlich ein wildes Durcheinander von Karnevalsscherzen, Experimenten neuer Sichtweisen und Konzepte, wissenschaftlicher Witze und schlichtem Nonsens. Jetzt besser formuliert. LG --PerfektesChaos 16:32, 9. Dez. 2016 (CET)
Assembler und Maschinensprache
Der Artikel erwähnt an mehreren Stellen Assembler und Maschinensprache so, als ob es sich hier bei um zwei unterschiedliche Programmiersprachen handeln würde. Dabei ist Assemblercode doch vor allem ein Mittel, um Maschinencode auf eine leserliche Weise zu illustrieren und eingeben zu können, wobei jede Assembler-Funktion mit ihren Parametern abhängig von der genutzten Architektur stellvertretend für die jeweilige von der CPU interpretierbare, binäre Instruktion steht.
Ferner wird geschrieben, dass man in Assembler, Maschinensprache und C Hardware-nah programmieren könnte und die Sprache C an dieser Stelle nicht zu den Hochsprachen gezählt. Dabei muss aus C-Code mit Hilfe eines Compilers erst einmal der Maschinencode generiert werden, weswegen auch C zweifelsfrei zu den Hochsprachen zählen sollte.
- Ich habe schon mal eigenhändig in Maschinencode "programmiert" - also direkt Hex-Werte eingegeben, um ein Programm zu schreiben. Das ist was ganz anderes, als Assembler zu programmieren.
- Dass "C zweifelsfrei zu den Hochsprachen zähl[e]" ist deine Meinung. Viele Programmierer sehen C eher als Zwischenstufe zwischen Hochsprache und maschinennaher Programmierung.
- --arilou (Diskussion) 11:20, 6. Aug. 2019 (CEST)
- Assembler ist spezifisch für eine Prozessorenfamilie oder einen Hersteller.
- Assembler bietet jedoch noch über Makros eine parametrisierte Programmierung, die dann in einem allerletzten Schritt auf genau einen bestimmten Prozessor zugeschnittenen Maschinencode generiert. Damit kann der gemeinsam für eine Familie geschriebene Code im letzten Schritt auf verschiedene Konfigurationen angepasst werden.
- Außerdem ist Maschinencode in seinen entsprechenden Assembler rückübersetzbar. Dabei entsteht ein etwas menschenfreundlicherer Code, also sehr viel umfangreicher und dafür in menschlicher Sprache oder mit mmemonischen Kürzeln. Der Informationsgehalt ist allerdings identisch.
- Die Einstufung von C als höhere Sprache ist zeitabhängig. Im letzten Jahrhundert war das sicher berechtigt gewesen; mittlerweile ist man etwas verwöhnter gewoden und guckt vom Level noch höherer Sprachen (beginnend mit C++) auf das Frühwerk herab.
- VG --PerfektesChaos 16:37, 7. Aug. 2019 (CEST)
- Aber es gibt doch auch verschiedene Assembler-Dialekte auf derselben Architektur. Ich habe einmal gehört, dass TASM-Code nicht mit MASM kompatibel war und umgekehrt. Das war aber noch unter DOS.
- Der Unterschied von Assembler und Maschinencode ist jedoch eindeutig, denn Maschinencode kann direkt ausgeführt werden, während Assembler zwar extrem Maschinennah ist, aber noch übersetzt werden muss.
- ‣Andreas•⚖ 19:01, 7. Aug. 2019 (CEST)
- @Assembler-Dialekte: Jeiiin. Im Prinzip ja. Heute praktisch eher nein.
- Auf den Chips des letzten Jahrhunderts konnte man noch mehrere Assembler konstruieren.
- Die Chips konnten kaum was, und wenn, dann alle etwa das Gleiche: Register rein, Register raus. Ein paar Grundrechenarten; Integer und als Luxus Gleitkomma-Operationen.
- Also brauchte man nur ein Mapping, das deren Opcodes auf die mnemotechnischen (menschenwürdigen) Bezeichner abbildete. Wobei jede Familie ihre eigenen Opcodes hatte; dann musste man halt konfigurieren, welche Tabelle man anwenden wollte.
- Außerdem eine Handvoll Konfigurationsparameter, die Eigenschaften des Chips abbildeten: Adresslänge, Anzahl der Register, nicht verwendbare oder zusätzliche Funktionen.
- Darüber lag dann noch eine Makro-Skript-Sprache, die plumpe Zeichenkettenersetzung machte, aber das Leben extrem erleichterte. Fertig.
- Damit konnte man sich im Prinzip Universal-Assembler schreiben, die für alle Chips am Markt funktionierten. Also auf jedem Chip den Assembler vom Hersteller oder jenen oder den von irgendeiner Uni benutzen. Das ging.
- Heutzutage sind die Teile aber lausig kompliziert geworden, und sich auch nicht mehr alle ähnlich: Es gibt Echtzeit-Video-Unterstützung, 3D-Raumberechnung (Ballerspiele), Kryptografie (Multimedia-Verschlüsselung), Audio-Codecs und was weiß ich. Dazu Multi-Core-Architekturen und mathematische Co-Prozessoren.
- Die komplexen neuen Funktionen haben nicht mehr Support von allen Assemblern, sondern nur von dem einen Assembler, den der jeweilige Hardware-Hersteller unterstützt, entwickelt und die neuesten Features vorbeugend einpflegt. Deshalb passt mittlerweile eigentlich nur noch eine Assembler-Linie auf eine Hersteller-Linie, weil es sich kaum lohnt, konkurrierende Assembler zu pflegen.
- VG --PerfektesChaos 22:20, 7. Aug. 2019 (CEST)
- Wir weichen vom Thema ab. Die ursprüngliche Kritik lautet (soweit ich das verstanden habe):
- "Assembler und Maschinencode ist doch (praktisch) dasselbe";
- "C ist zweifelsfrei eine Hochsprache".
- [Themenabweichend]: @PerfektesChaos: Du scheinst vor allem auf Risc-Systemen unterwegs gewesen zu sein? "Die Chips konnten kaum was" - schon ein 8086 hat ca. 100 Assemblerbefehle, +nochmal 100 für den 8087 (Gleitkommabefehle); bis zum i386 von 1985 sind ca. weitere 80 dazugekommen, +20 Floats (i387). Motorolas 68k-Linie war kaum anders. Obendrein bildete häufig ein "Assemblerbefehl" auf mehrere verschiedene Opcodes ab (bzgl. "einfaches Mapping" für den Assembler).
- --arilou (Diskussion) 09:11, 8. Aug. 2019 (CEST)
- Ja, ich denke bezüglich 1. "Assembler = Maschinencode" sind wir uns einig, nämlich nein, ist nicht dasselbe. Bezüglich 2. ist die Sache vermutlich nicht mehr so einfach. Allerdings gilt C als sehr maschinennahe, was allerdings nur für das reine C gilt, nicht für Objective C, C++, C# usw...
- ‣Andreas•⚖ 10:50, 8. Aug. 2019 (CEST)
Portal:Programmiersprachen
Hallo, ich schlage vor, das man ein eigenes Portal für Programmiersprachen macht. --C++ Programmierer (Diskussion) 15:07, 17. Mär. 2021 (CET)
- Wozu? Reicht das Portal:Informatik nicht? --Sebastian.Dietrich ✉ 17:44, 17. Mär. 2021 (CET)