Diskussion:Programmierung
Füge neue Diskussionsthemen unten an:
Klicke auf , um ein neues Diskussionsthema zu beginnen.Qualitätskriterien[Quelltext bearbeiten]
Hallo,
mich stören ein paar Sachen im Abschnitt "Qualitätskriterien" und ich wollte mal fragen, ob wir das verbessern könnten.
Zitat aus dem Artikel:
"Gute Programmierung[1] zeichnet sich zum einen dadurch aus, dass die Funktionen, die die jeweils verwendete Programmierumgebung bereitstellt, möglichst effizient genutzt werden."
Dass effiziente Nutzung von was-auch-immer "gut" ist, leuchtet ein. Aber mehr ist dem Satz auch nicht zu entnehmen. Die Bezeichnung "gute Programmierung" ist für mich viel zu allgemein. Es ist aus dem Artikel heraus unklar, in welchem Kontext der Autor der Quelle das Prädikat in Bezug auf Programmierung verwendet hat, aber jeder der sich mit Programmierung auskennt wird sich hüten, "gut" in diesem Zusammenhang zu definieren. "Gut" steht für viele Ziele, die sich jedoch teilweise sogar ausschließen. Beispiel: Performance und Speicherverbrauch. Dazu kommen noch viele, viele weitere Kriterien. Was "gute Programmierung" ist, kann heutzutage nur unter speziellen, gegebenen Umständen definiert werden.
Ist eine "Programmierumgebung" die IDE? Dann würde sich der Satz auf den Einsatz von Funktionalitäten der IDE (z.B. Syntaxhighlighting, Suche anhand regulärer Ausdrücke, Debugger und viele andere Dinge) beziehen. Das ist aber wohl nicht gemeint? Sollte man es nicht vielleicht durch "Programmiersprache" ersetzen? Nach Ersetzung würde ich den Satz so verstehen, dass die Konstrukte der Sprache effizient genutzt werden sollen. Damit gehe ich persönlich durchaus konform - auch wenn ich nicht sage, dass das "gute Programmierung" ist. Ein etwas "profanes" Beispiel: Statt
if (condition) {} else { ... }
schreibt man lieber
if (!condition) { ... }
Etwas bessere Beispiele: Verwendung von Zeigern und Referenzen für die Performance, Verwendung des Schlüsselwortes "const" (C++) um Programmierfehler schon zur Compilierzeit zu vermeiden, "return $var" statt "return($var)" bei PHP5 uvm. .
Gerade bei komplexeren Sprachen wie Perl ist diese Aussage in meinen Augen absolut nachvollziehbar und richtig. Was danach allerdings kommt, geht in eine ganz andere Richtung:
"Insbesondere geht es darum, für Aufgabenstellungen nicht das Rad neu zu erfinden, wenn bestimmte Funktionen schon durch die Programmierumgebung bereitgestellt werden (beispielsweise in Form von Bibliotheken). Sie zeichnet sich also vor allem dadurch aus, dass ein guter Überblick über den grundsätzlichen Funktionsumfang und die Systematik der von der Programmierumgebung bereitgestellten Funktionen (die in die tausende gehen können) erzeugt wird. Für eine definierte Aufgabenstellung können sie in entsprechenden Dokumentationen dann schnell die bereitgestellten Funktionen nachschlagen und einsetzen."
Erstmal: Da im vorherigen Satz "zum einen" gesagt wurde, sollte hier ein "zum anderen" / "weiterhin" oder so auftauchen. Das "zum einen" stellt auch eine Auflistung von Kriterien für "gute Programmierung" in Aussicht, die nicht erfolgt.
Ansonsten spielt der Absatz plötzlich nur noch auf Wiederverwendbarkeit an. Abgesehen davon, dass er plötzlich sehr fachspezifische Begriffe ("Funktionen") verwendet (was im Rest des Artikels übrigens desöfteren genauso passiert), setzt der Absatz die Bibliotheken der Sprache gleich, was auf jeden Fall ein grober inhaltlicher Fehler ist! Ich kann mir denken, wie die Autoren des Absatzes das gemeint haben und bin auch der Meinung, dass dieses grundlegende Wesen von Programmieren ("Programmieren heißt auch Konsumieren bzw. Nutzen fremder Arbeit in eigenem Kontext bzw. für eigene Zwecke [was auch die Sprache selber betrifft!]") hier erwähnt werden sollte - die Wiederverwendbarkeit selber ist aber eine komplexe Frage aus dem Gebiet der Programmierparadigmen und gehört hier nicht her.
Ich glaube, der Artikel sollte für den Otto-Normalverbraucher, der sich gerade fragt was Programmieren ist, einen guten Einstieg liefern und sich auf ganz allgemeine Gedanken beschränken. Der letzte Absatz von "Qualitätskriterien" macht das in etwa: Er schildert, dass Programmierer sich mit vielen Plattformen und robustem Quelltext auseinandersetzen müssen und dass das eine Herausforderung für Programmierer ist. Ich finde, der Artikel sollte unbedingt überarbeitet werden.
Wie seht ihr das?
--84.184.72.59 01:10, 11. Aug. 2009 (CEST)
Ergänzung:
Ich finde übrigens den Satz "Insbesondere geht es darum, für Aufgabenstellungen nicht das Rad neu zu erfinden [...]" sehr unsachlich und nicht für ein Lexicon passend. (Es ist zwar eine witzige Formulierung, aber hier am falschen Ort. Es geht ja bei Wikipedia darum, die Fakten genau darzustellen und nicht einen ungefähren Eindruck zu vermitteln.) (nicht signierter Beitrag von 95.118.62.178 (Diskussion | Beiträge) 00:33, 12. Feb. 2010 (CET))
Zustimmung durch 88.73.83.119 22:00, 16. Feb. 2010 (CET)[Quelltext bearbeiten]
Ich könnte kaum mehr zustimmen. Alleine daß der Abschnitt "Qualitätskriterien" die Hälfte des Artikels ausmacht ist schlecht proportioniert.
Er wirkt wie von jemandem, dem das gerade persönlich wichtig ist, und der seine Erkenntnisse irgendwie weitergeben will, dabei aber wenig Talent zeigt sich auszudrücken. Das ist aber im Rest des Artikels nicht besser.
"Programmieren ist das Erstellen von Programmen" - tja - etwas tautologisch, oder? Ein Programm ist demnach das Produkt des Programmierens?
Unter "Programmierumgebung" verstehe ich auch die IDE, und daß man diese effizient genutzt hat sollte man einem Programm gar nicht ansehen - es sollte agnostisch gegenüber der IDE sein, um wartbar und unabhängig zu bleiben, und auch von Nutzern anderer Umgebungen verstanden werden zu können.
Effizienz ist auch ein ökonomischer Maßstab, der in Programmierfragen nichts verloren hat. Nicht alle Programmierung ist Lohnarbeit, und die Perspektive auf kurzfristige Gewinnen ist Ideologie, und nichtmals Konsens in der Geschäftswelt, sondern vielmehr auch dort umstritten.
"Zunehmend wird er dabei durch Codegeneratoren unterstützt, " Das stimmt z.B. für mich nicht. Auch der Hinweis auf agile Programmierung ist so ein - wir schauen mal aus der Tür raus, und beschreiben anhand dessen, was wir sehen, was Wetter ist.
"Insbesondere geht es darum, für Aufgabenstellungen nicht das Rad neu zu erfinden, " Das Gegenteil ist genauso richtig. Programmieren ist die Tätigkeit für spezielle Aufgabenstellungen das Rad täglich neu zu erfinden. Selbst die Metapher mit dem Rad stimmt, wenn man sich nur unterschiedliche Räder anschaut. Für jeden PKW wird wieder das Rad neu erfunden, für Kinderwägen und Traktoren, für Flugzeuge und Schweizer Uhren, für Spielzeugautos, Lokomotiven, ICE-I, ICE-II und ICE-III - immer wieder erfindet dieser doofe Mensch das Rad neu. :)
"Dies verlangt ... sich nicht ... dazu verleiten lassen darf, zu kurzen, „kryptischen“ Quelltext zu erzeugen, " Zu kurzer Code ist zu kurz, wie zu bröckeliger Mörtel zu bröckelig ist. Eine Null-Aussage, wenn man genau hinschaut.
"Statistisch gesehen wird die meiste Zeit für die Entwicklung von Quelltext benötigt, um auf Fehler oder außergewöhnliche Anwendungs- oder Hardwareumgebungen zu reagieren." Ist das so? Quelle?
"Ein Programmtext, der auch bei unvorhergesehenen Fehlern oder ungewöhnlichen Umgebungen sinnvoll reagiert, wird als portabel oder robust bezeichnet." Nein, der wird als robust bezeichnet. Portabel ist was anderes.
"Geübte Programmierer können die möglichen Fehler und Laufzeitumgebungen gut einschätzen und strukturieren das Programm und seinen Quelltext dementsprechend." "Geübte Schreiner können die möglichen Fehler und Umgebungen gut einschätzen und strukturieren das Möbel und seine Bauanleitung dementsprechend." Triviales Bla-bla.
"Der Zeitdruck bei der Entwicklung von Anwendungen stellt selbst an erfahrene Programmierer immer höchste Ansprüche hinsichtlich dieses Kriteriums." Schwachsinn. Das ist eine pauschale Behauptung über die Bedingung der Entwicklung von Programmen, die zutreffen kann oder nicht, aber nichts mit Programmieren zu tun hat, sondern mit dem Gesellschaftssystem in dem dies stattfindet.
Ein programmierender Student, ein Hobbyprogrammierer, ein bestens ausgestattetes Projekt muß nicht Zeitdruck ausüben.
"von der Programmierumgebung bereitgestellten Funktionen (die in die tausende gehen können) erzeugt wird." Was soll das? In die tausende? Oder Zehntausende vielleicht? Oder Hunderttausende? Wenn die Zahl aus der Luft gegriffen ist, was soll das dann?
- WP:Sei mutig und hilf mit. (P.S: gebe Dir übrigens in allen Punkten recht) --Sebastian.Dietrich 22:47, 16. Feb. 2010 (CET)
Qualitätskriterien neu schreiben[Quelltext bearbeiten]
So - hab mir jetzt endlich den Absatz Qualitätskriterien durchgelesen. Puh was für ein Blödsinn. Der ganze Abschnitt ist mMn so überhaupt nicht haltbar --> habe ihn auf die QS gesetzt --> bitte dort weiterdiskuttieren. --Sebastian.Dietrich 17:12, 2. Mär. 2010 (CET)
Programmierung umbenennen in Computerprogrammmierung?[Quelltext bearbeiten]
Hallo.
Ich stolperte über diesen Artikel weil ich nachschlagen wollte, was "programmierung" übergreifend bedeuet. Schließlich gibt es z. B. auch die neurolinguistische Programmierung (siehe http://de.wikipedia.org/wiki/Neurolinguistische_Programmierung), die mit der Programmierung von Software nicht das geringste zu tun hat. Von daher finde ich es irreführend, den Allgemeinbegriff "Programmierung" auf die Erstellung von Software festzunageln.
Wäre es nicht besser, diesen Artikel "Computerprogrammierung" zu nennen und stattdessen Programmierung übergreifend zu erläutern?
Beste Grüße
-- DanyelAndre 18:00, 29. Mär. 2011 (CEST)
- Nein, weil unter Programmierung wie hier im Artikel beschrieben versteht man nicht nur die Programmierung von Computern (sondern die von Automaten). Ich hab aber jetzt mal die Begriffsklärung am Artikelbeginn zumindest um NLP ergänzt. --Sebastian.Dietrich ✉ 19:47, 29. Mär. 2011 (CEST)
- Im Besonderen wir hinlänglich unter Programmierung die Programmierung von Software verstanden, mit ein Grund weshalb das Lemma wie es jetzt ist völlig korrekt ist. Wie du, bin ich schon oft auf Lemmas gestoßen unter denen ich mir etwas anderes erwartet habe. Die Erklärung ist dann eben, dass das eine Thema passender für das Lemma ist. LG, ひき肉器 公議 16:42, 30. Mär. 2011 (CEST)
- NLP hat in der Tat nicht das Geringste mit Softwareprogrammierung zu tun. Das "Programmieren" in NLP ist eine Metapher. Deshalb wäre eine Verschiebung zu "Computerprogrammierung" unsinnig. --JoVV 18:03, 14. Jul. 2011 (CEST)
Auch zwölf Jahre später würde ich immer noch für diese Umbennenung plädieren, was jetzt aber nichts mit NLP zu tun hat. Der ganze Artikel ist eine unzulässige Verengung auf Computer und Software. Historisch gesehen wurden auch z. B. auch Webmaschinen oder Musikautomaten programmiert – durch Lochbänder etwa. Jedes Loch beinhaltete eine Anweisung, etwa einen einzelnen Kettfaden hochzuziehen oder einen bestimmten Ton zu spielen. Die Lochkarte war das Programm, deren Fertigung Programmierung. Bezeichnend ist, das Lochkarten auch später noch in den ersten Jahrzenten des Computers eine wichtige Rolle spielten.
Womit wir bei einem Unterschied sind, der heutzutage gerne unterschlagen wird, der zu meiner Zeit (80er Jahre) aber noch gemacht wurde:
- Hardwareprogrammierung
- Softwareprogrammierung
- und irgendwo dazwischen Firmwarprogrammierung
Ersteres war in der Anfangszeit der Computerei die übeliche Form der Programmierung. Computer hatten keinen Programmspeicher, in den man hinein hätte programmieren können. Das bisschen Speicher war im wesentlichen für Zwischen- und Endergebnisse von Berechnungen. Die Befehle wurden von Lochkarte oder -streifen gelesen und ausgeführt. Oder man hatte Stecktafeln in die das Programm „eingestöpselt“ wurde. Das Programm war „in Hardware“ und konnte (mangels Programmspeicher) nicht in Software umgewandelt werden.
Softwareprogrammierung dagegen, also der heute verbreitete Zustand, setzt einen Programmspeicher voraus, wobei es erstmal egal ist, ob der Speicher universell ist, also für Programm und Daten, oder nach Programm und Daten getrennt, wie man das auch heute noch bei Mikrocontrollern findet. Wesentlich ist, dass das Programm im Speicher steht – auch wenn es vielleicht von einem Datenträger dorthin geladen wurde. --Duschgeldrache2 (Diskussion) 00:06, 25. Dez. 2023 (CET)
- Ich wiederum finde, dass hier der Begriff "Computer" einschränkend in der Definition "Mikrocomputer" verwendet wird: es gibt auch analoge oder mechanische Computer, und die werden auch programmiert. Die Zuse Z1 war ein mechanischer Computer, ebenso wie zuvor die (damals unvollendete) Analytical Engine.
- Es gibt jedoch einen entscheidenden Unterschied zwischen einem Universalrechner, der Turing-Vollständigkeit besitzt, und einer Rechenmaschine, die in Hardware bereits festgelegte "Programm-Eigenschaften" besitzt, die eine Verwendung als "universelle Rechenmaschine" ausschließen. Zu letzterer zählen die Webmaschinen und Musikautomaten.
- Für einen anderen Programmierungsbegriff als jenen von Computern sollte es jedoch Quellen geben. Ohne Quellen ist die Diskussion hier wohl sinnlos, oder nicht?
- ‣Andreas•⚖ 00:22, 25. Dez. 2023 (CET)
Auch ein Interpreter 'übersetzt'[Quelltext bearbeiten]
In den letzten Änderungen [1] wurden Textteile entfernt, gemäß denen auch Interpreter eine "Übersetzung" vornähmen - dies wird damit also verneint. Ich denke, dies trifft lediglich für den Aspekt zu, dass ein Interpreter keinen ausführbaren Code als zusätzliche(n) Datei/Bibliothekseintrag erzeugt. Trotzdem muss er, da er dem Prozessor ausführbare Befehle bereitstellen muss, den Originalcode genauso 'übersetzen' - nur pro Anweisung oder Anweisungsblock; wie es auch in Interpreter beschrieben ist. Dies ist im aktuellen Text nicht mehr enthalten. --VÖRBY (Diskussion) 09:56, 20. Aug. 2019 (CEST); Link ergänzt: --VÖRBY (Diskussion) 10:30, 24. Aug. 2019 (CEST)
Feedback? Andernfalls sollten wir 'Interpreter' wieder reinnehmen, möglichst mit einem von 'Compiler' differenzierenden Hinweis.--VÖRBY (Diskussion) 17:07, 23. Aug. 2019 (CEST)
Im aktuellen Artikel ist die Aussage zum 'Compiler' in der Einleitung nicht mehr vorhanden. An anderen Stellen ist auch der Interpreter als Übersetzer erwähnt. Das genügt.
Weitläufige Änderungen[Quelltext bearbeiten]
Es geht um die weitläufigen Änderungen mit [2]. Die Einleitung ist bereits jetzt schon viel zu umfangreich und sollte verschlankt und nicht noch mehr aufgeblasen werden. Die Änderungen sind zwar gut gemeint, aber nicht gut umgesetzt - d.h. bitte einzeln einbringen (damit sie auch einzeln von anderen Autoren reflektiert werden können) oder einzeln hier besprechen... --Sebastian.Dietrich ✉ 08:12, 20. Jun. 2023 (CEST)