Diskussion:Deklarative 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 ?

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)Beantworten

--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)Beantworten

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?

„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.)