Diskussion:Deklarative Programmierung/Archiv/1
Architekturunabhängigkeit
Mir ist nicht ganz klar, wieso Architekturunabhängigkeit ein spezielles Merkmal deklarativen Programmierens sein sollte. Die existierenden deklarativen Sprachen mögen architekturunabhängig sein, aber hat dieser Umstand System oder ist er Zufall? Warum?
Das mal ganz abgesehen davon, daß der Punkt »Architekturunabhängigkeit« rein stilistisch nicht in die Liste paßt, weil Mischung von Nominal- und Verbalstil nicht gerade schön ist... --Mulk 16:33, 24. Jul 2006 (CEST)
- Ich sehe das ebenso und entferne den Punkt. Falls ihn jemand wieder einfügt, schreibt er ja vielleicht noch etwas erklärenden Text dazu. --jpp ?! 20:24, 24. Jul 2006 (CEST)
- Ich denke, der Punkt Architekturunabhängigkeit ist durch die erhöhte Abstraktion gegeben. Gerade der Punkt ein Programm nach dem "Was" und nicht nach dem "Wie" zu schreiben, lässt doch eine gewisse Systemunabhängigkeit schließen. Man beschreibt eben nicht "wie" das System es zu lösen hat (also was in welchen Speicher geschrieben werden muss), sondern nur noch was man haben will. Einwände? --pindar 22:50, 26. Jan. 2009 (CET)
„Repititive Rekursion“
Aus dem Artikel:
- Hauptkontrollstruktur bildet die Rekursion, insbesondere aus Effektivitätsgründen die repetitive Rekursion.
Meint „repetitive Rekursion“ hier dasselbe wie Endrekursion? — Tobias Bergemann 14:04, 26. Jul 2006 (CEST)
- ist identisch, deswegen habe ich gleichmal verlinkt. gruß --Murkel (anmurkeln) 17:46, 26. Jul 2006 (CEST)
Geschwindigkeit
Ich las, dass der besagte Quicksort in seiner Pascal-Variante schneller + umfassender waere als der in Haskell, woran liegt das? Wenn beides kompiliert wird sollte sich das ja erledigt haben? Und Quicksort bleibt halt auch Quicksort was den Aufwand im O-Kalkuel angeht. Bleibt noch die Uebersichtlichkeit+Wartbarkeit der Implementation fuer die programmierende Person uebrig als Grund fuer die funktionale Programmierung. Oder ist der Geschwindigkeitsnachteil doch nicht so gross? Bitte mehr dazu!
- Zum Thema Geschwindigkeit kann ich sagen, dass der naive, hier gezeigte Algorithmus tatsächlich nicht der schnellste ist (Begründung werde ich noch liefern). Jedoch kann ich auch Mitteilen, dass es eine effizientere Lösung gibt:
quicksoftfast :: Ord a => [a] -> [a] quicksoftfast xs = qs xs [] where
qs [] acc = acc
qs (x:xs) acc = let (ys, zs) = partition (<x) xs
in qs ys (x:qs zs acc)
(Quelle: Skript "Funktionale Programmierung" von Martin Griebl, Christoph Herrmann (c) Univ. Passau, Prof. Lengauer, Ph.D.) --pindar 22:50, 26. Jan. 2009 (CET)
Leichter zu verstehen?
"Die Programme sind kürzer und leichter zu verstehen als vergleichbare imperative Programme." Also dem kürzer würde ich ja zustimmen, aber leichter zu verstehen? Wirklich? Gibt es dazu Untersuchungen? Viele Menschen sind doch eher eine imperative Herangehensweise gewöhnt (z.B. auch Rezepte, Bauanleitungen und ähnliche Handlungsanweisungen), so dass imperative Algorithmen vermutlich eher leichter zu verstehen sind. Wenn es dazu keine Untersuchungen gibt, die diese Behauptung belegen, würde ich doch empfehlen, es zu entfernen.-- 85.177.222.152 02:16, 27. Dez. 2011 (CET)
Unterschied zur imperativen Programmierung
Dieser Artikel beschreibt im Wesentlichen nur den Unterschied zur imperativen Programmierung. Im Artikel Programmierparadigma fehlt eine ordentliche Übersicht (siehe Diskussion dort), die Aussage, das ganze Paradigma der deklarativen Programmierung sei akademisch, stimmt gegebenenfalls nicht. Nur die konkreten Vertreter sind es.
XSLT ist nicht imperativ, wahrscheinlich eher deklarativ (wird im Artikel Programmierparadigma als Regelbasierende Programmierung bezeichnet, und ist anerkannter verbreiteter Stand der Technik. Sollte das hier ggf. als positives Beispiel erwähnt werden ?
--HartmutS 10:19, 18. Feb 2006 (CET)
- das imperative programmierparadigma ist den meisten menschen vertraut. aus diesem grund erfolgt die gegenüberstellung. im artikel Programmierparadigma sollte wirklich nur kurz etwas zu jedem paradigma stehen, da das lemma bei dieser fülle an aufgeführten arten schnell unübersichtlich wird. vielmehr sollte man sich dort auf die geschichtliche entwicklung (und eventuelle schnittmengen) konzentrieren. gruß--Murkel (anmurkeln) 13:11, 22. Feb 2006 (CET)
- XSLT gehört als Beispiel für eine deklarative Programmiersprache unbedingt in den Artikel hinein. Heute wird sie wahrscheinlich mehr benutzt als jede andere Sprache dieser Familie. --Thüringer ☼ 12:30, 17. Dez. 2008 (CET)
SQL
Wie sieht es mit SQL aus? Ich beschreibe dort im Grunde ja auch das Resultat und nicht, wie dieser erzeugt wird... Dani 17:01, 21. Jul. 2008 (CEST)
Quelle für die Behauptungen in der Nachteile Sektion
"Performanz: Der angegebene Quicksort-Algorithmus läuft in Pascal wesentlich schneller als in Haskell und ist demnach für die Verarbeitung größerer Datenmengen besser geeignet. Deklarative Programmierparadigmen stehen insbesondere imperativen und objektorientierten Paradigmen in ihrer Akzeptanz nach. Man spricht gern von sogenannten Akademiker-Sprachen."
Schöne Behauptungen, vor allem ersteres sollte bewissen werden. "Wesentlich" schneller...lächerlich. In der zweiten Behauptung wird von Akzeptanz gesprochen. Akzeptanz von wem bitte? Diese Sektion liest sich sehr gefärbt und ist mehr als überflüssig. (nicht signierter Beitrag von 2A02:810D:1C0:1698:4B9:6A6B:F27B:A301 (Diskussion | Beiträge) 22:17, 15. Sep. 2016 (CEST))
lisp ist nicht deklarative
ausserdem fehlen in den Beispielen noch: make und icon
Gruß (nicht signierter Beitrag von 2.247.245.12 (Diskussion) 12:44, 25. Feb. 2017 (CET))
„Deklarativ“ vs. „deskriptiv“
Wird mitunter auch deskriptive Programmierung genannt. Füge eventuell Erläuterung, Belege ein und eine Weiterleitung auf diesen Artikel. -- Lilalas (Diskussion) 17:03, 5. Okt. 2017 (CEST)
Quckcrash-Algorithmus!
Oder: a := [ 1 2 3 2 1 ];
Und dann: quicksort(3,5). Oder doch lieber gleich quicksort(99999,0)? (nicht signierter Beitrag von 84.166.43.135 (Diskussion) 01:29, 31. Mär. 2024 (CET))