Exotische Prog.Sprachen

Brutus

Kingruedi, kannst du mir das mal genauer erklären, wieso LISP für KI so gefragt ist? Ich meine, man kann mit Listen rumspielen bzw. sie sind _DIE_ basis, aber inwiefern ist das jetzt besser als brainfuck, haskell, c oder sonstwas?
Und wieso ist es gut - sehr gut geeignet für Textverarbeitung? (Ja, ich habe noch nicht viel mit LISP gemacht, mache gerade dieses Tutorial dieser uni Seite..)

maximAL

Helium schrieb:

Die Lösung sind IMHO Mischsprachen, wie Scala, die zwar noch nicht hundertprozentig ausgereift ist

ich möchte nur nochmal anmerken, dass OCaml auch ein "mischsprache" ist. funktional und imperativ - auch objektorientiert .
keine ahnung, ob es ausgereifter als scala ist, das kenn ich nämlich nicht

paedubucher

Ich habe eine Zeit in Visual Basic 6 programmiert. Wer jetzt sagt, das sei nicht exotisch, der hat wohl noch nie die Syntax gesehen

Ausserdem gibt es in VB sehr abenteuerliche Auslegungen von Objektreferenzen:

Dim obj As New Object
obj = Nothing

'Jetzt kommt es :-D
if obj = Nothing 'Diese Zeile verursacht einen schönen Absturz
    ...

Für mich absolut unlogisch, stellt eine riesengrosse Einschränkung in der Sprache VB dar. In C/C++, C# und auch in JAVA kann man so wunderschön auf NULL-Referenzen prüfen, in VB geht das offenbar nicht...

Oder hat gleich jemand einen Tipp?

@Helium:

Ist Scala wirklich so extrem effizient hinsichtlich Software-Entwicklung ?
Das im "Scala by example" abgedruckte Quicksort braucht über 20 Zeilen
Quelltext, das ist auch etwa die Größe der C-Version.

In Haskell oder auch LISP kann man Quicksort ja in zwei bis fünf Zeilen
programmieren.

Da wir schon beim Thema sind: Was hältst Du eigentlich von Helium (die
Programmiersprache, nicht der Poster ) ? Ist das
zum Lernen von Haskell brauchbar oder kann man Helium auch zur größeren
Anwendungsprogrammierung verwenden ?
Wieviel Aufwand erfordert ein späteres Umsetzen von Helium-Code in Haskell-Code?

Helium

Cacheline schrieb:

@Helium:

Ist Scala wirklich so extrem effizient hinsichtlich Software-Entwicklung ?
Das im "Scala by example" abgedruckte Quicksort braucht über 20 Zeilen
Quelltext, das ist auch etwa die Größe der C-Version.

In Haskell oder auch LISP kann man Quicksort ja in zwei bis fünf Zeilen
programmieren.

object sort1 {

   def sort(a: List[Int]): List[Int] = {
      if (a.length < 2)
         a
      else {
         val pivot = a(a.length / 2);
         sort(a.filter(x => x < pivot))  
            ::: a.filter(x => x == pivot)  
            ::: sort(a.filter(x => x > pivot))
      }
   }

   def main(args: Array[String]) = {
      val xs = List(6, 2, 8, 5, 1);
      Console.println(xs);
      Console.println(sort(xs))
   }

}

Das sind 10 Zeilen für den Algorithmus. Außerdem kommt es nicht ausschließlich auf die Zeilenzahl an.

Beispielsweise sind Comprehensions in Scala länger, als in Haskell, allein schon, weil man das Wort 'for' schreiben muss. Aber es geht vielmehr darum, dass man Sie überhaupt einsetzen kann. Außerdem funktionieren sie in Haskell nur mit Listen, in Scala kann man beinahe jede Collection entsprechend ausrüsten (solange es sinn macht).

Sorry, ich will Scala ja nicht disqualifizieren, kenne das auch gar nicht.
Aber in Haskell kann man Quicksort in 3 Zeilen programmieren, s. "a Gentle Introdutction to Haskell 98".

Was mir an Haskell auf den ersten Blick gut gefällt, ist, daß endlich mal Dinge syntaktisch so dargestellt werden können wie sie
in der Mathematik dargestellt werden (Mengennotation, Abbildungsnotation usw...)
und daß Haskell eine Standard-Sprache für FP sein will.

Ich habe aber immer noch keine Antwort auf meine eigentliche Frage erhalten:
Wieso behaupten FP-Vertreter immer wieder, man könne mit Sprachen wie
Haskell 10-mal so effizient entwickeln, da die Sourcen 10-mal kürzer und damit
10-mal fehlerfreier würden, aber alle Welt in C/C++ programmiert ?
Wenn die Behauptung stimmte, wieso verschenken fast alle Software-Hersteller
dann 90% ihrer Resourcen an Entwicklungs- und Testzeit anstatt auf FP
umzusteigen ?

Walli

Vielleicht, weil es nicht annähernd so einfach ist ein Programm in einer funktionalen Sprache zu entwickeln?

Helium

Cacheline schrieb:

Sorry, ich will Scala ja nicht disqualifizieren, kenne das auch gar nicht.
Aber in Haskell kann man Quicksort in 3 Zeilen programmieren, s. "a Gentle Introdutction to Haskell 98".

Ich kenne Haskell und ich weiß, dass die Notation extrem kurz ist. Dennoch sage ich, dass sich viele Dinge in Haskell nicht so einfach programmieren lassen, wie in der objektorientierten Programmierung (, die Scala perfekt beherscht).

Was mir an Haskell auf den ersten Blick gut gefällt, ist, daß endlich mal Dinge syntaktisch so dargestellt werden können wie sie in der Mathematik dargestellt werden (Mengennotation, Abbildungsnotation usw...) und daß Haskell eine Standard-Sprache für FP sein will.

Ein Mathematiker könnte sich jetzt auch beschweren, dass die Symbole der Mengenlehre hier für andere Dinge missbraucht werden, nähmlich Listen. Außerdem ist die genaue Syntax nicht ganz so entscheident:
Haskell:
[x * x | x <- y, x > 0]
Python:
[x * x for x in y if x > 0]
Scala:
for (val x <- y; x > 0) yield x * x

Ich habe aber immer noch keine Antwort auf meine eigentliche Frage erhalten:
Wieso behaupten FP-Vertreter immer wieder, man könne mit Sprachen wie
Haskell 10-mal so effizient entwickeln, da die Sourcen 10-mal kürzer und damit
10-mal fehlerfreier würden, aber alle Welt in C/C++ programmiert ?
Wenn die Behauptung stimmte, wieso verschenken fast alle Software-Hersteller
dann 90% ihrer Resourcen an Entwicklungs- und Testzeit anstatt auf FP
umzusteigen ?

Weil es zu vielen Dingen einfach nicht passt. Wenn ich eine Checkbox in meinem GUI habe, dann hätte ich im Code auch gerne ein entsprechendes Objekt, dass diese Checkbox repräsentiert. Ich möchte diese Objekt befragen können, ob die Checkbox gesetzt ist oder nicht. Das ist für mich die intuitive Variante. Dazu muss sie aber ihren Zustand speichern.
In einer rein funktionalen Sprache, wie Haskell gibt es aber keinen Zustand. Etwas so alltägliches, wie ein einfaches GUI-Element lässt sich nicht auf intuitive Weise in der Sprache realisieren (zumindest kenne ich keinen Weg). Man kann dann mit Monaden rumbasteln, aber es wird nie so einfach werden, wie in einer gewöhnlichen objektorientierten Sprache.
Oder zeig mir mal einen rein funktonalen Hash, der auch eine entsprechende Geschwindigkeit aufzeigen kann.

Funktionale Programmierung ist kein allheilmittel. Im Gegenteil. Für viele altägliche Dinge ist sie ganz eifnach ungeeignet.
(Natürlich ist genauso die imperative Programmierung für viele Dinge ungeeignet und die funktionale Programmierung hätte deutliche Vorteile.)

paedubucher schrieb:

Ich habe eine Zeit in Visual Basic 6 programmiert. Wer jetzt sagt, das sei nicht exotisch, der hat wohl noch nie die Syntax gesehen

Ausserdem gibt es in VB sehr abenteuerliche Auslegungen von Objektreferenzen:
Dim obj As New Object
obj = Nothing

'Jetzt kommt es :-D
if obj = Nothing 'Diese Zeile verursacht einen schönen Absturz
    ...
Für mich absolut unlogisch, stellt eine riesengrosse Einschränkung in der Sprache VB dar. In C/C++, C# und auch in JAVA kann man so wunderschön auf NULL-Referenzen prüfen, in VB geht das offenbar nicht...

Oder hat gleich jemand einen Tipp?

Wow, sowas von peinlich. Ein Absturz kommt bei mir, VB6, nicht.
Geht auch garnicht, in drei 3 Zeilen Code, 3 dicke Fehler, zwei
davon 2 Syntaxfehler die nicht mal ein VB-Anfänger machen würde
und ausserdem verhindern das daraus ein ablauffähiges Programm
entstehen KANN.
Das überzeugt mich zumindest das du von VB6 NULL Ahnung hast.

In diesem Sinne hast du dich mit diesem Beitrag gründlich
blamiert.

Das du (paedubucher) jemals in VB6 (produkiv) programmiert hast halte ich für
völlig ausgeschlossen.

Dim obj As New Object

Geht nicht, Objekt ist kein konkreter Typ sondern steht für das COM-Interface
IDispatch. Dieses Interface kann man anfordern, aber man kann kein Objekt
davon neu erstellen. Wenn du Ahnung von COM-Programmierung hättest würdest
du dich nicht darüber wundern.

obj = Nothing

Objekte werden num nal mit Set zugewiesen Syntaxfehler 1

Set obj = nothing

if obj = Nothing

Auf nothing wird num mal mit is verglichen. Das fehlende then hast du sich nur
aufgrund des Platzmangel weggelassen. Syntaxfehler 2

if obj is nothing then...

Und das in 3 Zeilen Code.

Funktionale Programmierung ist kein allheilmittel. Im Gegenteil. Für viele altägliche Dinge ist sie ganz eifnach ungeeignet.<<

Das ist auch mein Eindruck, zumindest nach oberflächlicher Betrachtung von
LISP und Haskell und einigen kleinen Experimentier-Programmen damit.

Wie kommt es aber dann, daß in Literatur und Papers zum Thema FP immer
wieder darauf verwiesen wird, daß Leute, die einmal an FP gewühnt sind,
"gar nichts Anderes mehr haben wollen", wenn schon die Programmierung eines
Checkbuttons Probleme bei FP aufwirft ?

Es scheint doch nun, nach 45 Jahren der Diskussion "imperative Programmierung
vs. funktionale Programmierung", an der Zeit zu sein, daß die FP-Vertreter
die These von der Überlegenheit der FP unter Beweis stellen, indem sie,
sagen wir mal, einen Flugsimulator oder ein Office-Paket in einer
FP-Sprache programmieren und damit 10-mal so schnell fertig sind wie
die bekannten Projekte, die in imperativen Sprachen programmiert sind.

(Natürlich ist genauso die imperative Programmierung für viele Dinge ungeeignet und die funktionale Programmierung hätte deutliche Vorteile.)<<

Glaube ich gerne, zumindest was AI, Logik-Kalküle, Sprachensynthese oder andere Nischen-Anwendungen betrifft.

JBeni

Apropos GUI + Haskell: Es gibt durchaus Libraries dazu. Wie gut die sind kann ich nicht beurteilen (ein paar Projekte scheinen auch tot zu sein).
IMHO ist dies das grosse Problem: Keine Libraries -> niemand benutzt Haskell -> keine Libraries...
Solange es um Algorithmen (z.B. Parsen, etc) geht, glaub ich schon, dass Haskell 10 mal schneller in der Entwicklung ist.
Wenn es um grössere Mengen Daten geht, die auch noch in zufälliger Reihenfolge gelesen/geschrieben werden, habe ich allerdings meine Zweifel.

maximAL

Cacheline schrieb:

Wie kommt es aber dann, daß in Literatur und Papers zum Thema FP immer
wieder darauf verwiesen wird, daß Leute, die einmal an FP gewühnt sind,
"gar nichts Anderes mehr haben wollen"

vielleicht programmieren diejenigen etwas, was einen mit imperativer programmierung zum wahnsinn treiben würde?...

Wie gesagt, es besteht kein Zweifel daran, daß LISP und Verwandte, Haskell,
ML und Verwandte für bestimmte Anwendungen wie AI oder Parsen besonders geeignet sind.

Ich würde nur eben gerne wissen, ob die 10-fach erhöhte Effizienz der Programmentwicklung auch bei "Brot-und-Butter"-Anwendungen wie Office-Paketen und Graphiksoftware erreichbar ist oder ob sich dies auf die besagten Nischenanwendungen beschränkt. Ich nehme an, die Möglichkeit, Entwicklungszeit
und Fehlerfreiheit um den Faktor 9 bis 10 zu verbessern, dürfte für jeden
Entwickler interessant sein.

Ich bin überzeugt, daß Sprachen wie Haskell für die Software-Entwicklung neue Perspektiven eröffnen und bei vielen Algorithmen eine programmtechnische Eleganz und Durchsichtigkeit
ermöglichen, die die von weiter verbreiteten Sprachen weit übersteigt, das ist
keine Frage - vor allem ist Haskell viel näher am von der Mathematik gewohten
Formalismus. Vieles, was man mit C++ recht umständlich z.B. über STL-Methoden programmieren muß, geht ja mit Haskell offensichtlich weit einfacher und schlüssiger.

Ich will aber weder der imperativen noch der funktionalen Programmierung das
Wort reden, habe von letzterer auch kaum Ahnung, deshalb frage ich ja.

Aber offenbar gibt es auf die Frage (noch) keine allgemeingültige Antwort,
wahrscheinlich weil FP-Sprachen zu wenig verbreitet sind und damit realisierte
Projekte im Vergleich mit der Anzahl von Projekten in C/C++ selten sind.

Th

Der Unterschied von funktionalen Sprachen zu imperativen Sprachen besteht haupsächlich aus der Denkweise, wie man Problem angeht und sie dann in der Sprache löst.
In imperativen Sprachen muß man sich um Nebensächlichkeiten (bezogen auf das Problem), wie z.b. Speicherallokation, Variablenverwaltung etc., beschäftigen.
Funktionale Programme sind eleganter, aber eben nur für bestimmte Zwecke geeignet, also Systemprogramme wird man damit nicht erstellen können (da sie keine Resource verwalten können), aber jedliche Art von Algorithmus läßt sich erstmal bequem in Haskell, Clean, Miranda oder Gofer erstellen und dann auf eine Zielsprache portieren...

Meine Diplomarbeit bestand darin ein 50.000 Zeilen Programm (in C) in eine funktionale Sprache (Gofer) zu bringen. Zum einen war das C-Programm selbst undokumentiert und völlig unleserlich (die Hauptfunktion bestand aus drei ineinander verschachtelten Schleifen mit ca. 1000 Zeilen), und zum anderen hatte ich aber eine generelle Doku über das Problem (Patternmatching auf langen Strings, z.B. Gen-Sequenzen).

Zum Schluß hatte mein Gofer-Source-Code selbst nur knapp 1000 Zeilen, wobei der größte Teil für den Combinator-Parser benötigt wurde.

Leider funktionierte der Gofer-Compiler nicht richtig (da ich Arrays verwendet hatte), so daß ich leider keinen Geschwindigkeitsvergleich durchführen konnte).

Wenn ich heute in C++ programmiere, schreibe ich mir meist erstmals den Algo in funktionaler Weise auf, ehe ich ihn dann implementiere.

Hier noch Quicksort in Miranda:

qs [] = []

++ qs [v | v<-xs; v >=x]

Einfach und elegant...

Cacheline schrieb:

Wie kommt es aber dann, daß in Literatur und Papers zum Thema FP immer
wieder darauf verwiesen wird, daß Leute, die einmal an FP gewühnt sind,
"gar nichts Anderes mehr haben wollen", wenn schon die Programmierung eines
Checkbuttons Probleme bei FP aufwirft ?

Ich glaube, sie meinen in Wirklichkeit gar nicht die reine Lehre der striken FP. Aber FP-Programmiersprachen (bzw. Hybride) bringen Closures, (oft) dynamische Typisierung, "first class citizen" Funktionen hoeherer Ordung usw mit. Alles schoene Sachen, die in professioneller Hand wirklich produktiv sein koennen.

Laut Paul Graham macht die dynamische Typisierung + Makros + Closures die Benutzung von OOP ueberfluessig, warum, habe ich noch nicht verstanden.

Cacheline schrieb:

Es scheint doch nun, nach 45 Jahren der Diskussion "imperative Programmierung
vs. funktionale Programmierung", an der Zeit zu sein, daß die FP-Vertreter
die These von der Überlegenheit der FP unter Beweis stellen, indem sie,
sagen wir mal, einen Flugsimulator oder ein Office-Paket in einer
FP-Sprache programmieren und damit 10-mal so schnell fertig sind wie
die bekannten Projekte, die in imperativen Sprachen programmiert sind.

Hmm, die IDE fuer Allegro Common Lisp ist in Lisp geschrieben, die ist so aehnlich wie die Borland-IDEs, inkl. GUI-Designer usw. Allerdings wird auf CLOS zurueckgegriffen.. fuer strikte FP-Sprachen gebe ich dir recht.

-Gunnar

maximAL

(Gunnar) schrieb:

Laut Paul Graham macht die dynamische Typisierung + Makros + Closures die Benutzung von OOP ueberfluessig, warum, habe ich noch nicht verstanden.

nunja, FP bietet andere möglichkeiten der abstraktion und wiederverwendbarkeit etc. als OOP...

maximAL schrieb:

(Gunnar) schrieb:

Laut Paul Graham macht die dynamische Typisierung + Makros + Closures die Benutzung von OOP ueberfluessig, warum, habe ich noch nicht verstanden.

nunja, FP bietet andere möglichkeiten der abstraktion und wiederverwendbarkeit etc. als OOP...

Makros haben nicht viel mit FP zu tun. Die bremsen FP eher aus..

Aber mal ein einfaches Beispiel, wie man zB Daten mit einer Closure kapseln kann:

(defun point (x y)
  #'(lambda (op)
      (case op
	((val-x) x)
	((val-y) y)
	((dist) (sqrt (+ (* x x) (* y y)))) ; abstand zum ursprung
	(otherwise nil))))

CL-USER> (defvar foo (point 4 7))
FOO
CL-USER> (funcall foo 'val-x)
4
CL-USER> (funcall foo 'dist)
8.062258
CL-USER> val-x     ;; <-- ist hier [b]nicht[/b] gebunden.
; Evaluation aborted

Mit ein paar STLerweiterungen lässt sich Quicksort auch sehr elegant in C++ implementieren.

template<class container>
container quick_sort(const container&con)
{
  if(con.size() < 2)
    return con;
  else
    return quick_sort(select_if(con, _1 < con.front())) + 
      select_if(con, _1 == con.front()) + 
      quick_sort(select_if(con, _1 > con.front()));
}

Gebraucht wird boost lambda und

template<class container, class fuctor>
container select_if(const container&con, const fuctor&cond)
{
  container out;
  container::const_iterator i = con.begin(), end = con.end();
  for(;i!=end;++i)
    if(cond(*i))
      out.push_back(*i);
  return out;
}

template<class container>
container operator+(container a, const container&b)
{
  copy(b.begin(), b.end(), back_inserter(a));
  return a;
}

Ist also mehr ein Problem der STL und des lächerlich langsamen Process der Sprachweiterentwickelung also wirklich von der Sprache.

In imperativen Sprachen muß man sich um Nebensächlichkeiten (bezogen auf das Problem), wie z.b. Speicherallokation, Variablenverwaltung etc., beschäftigen.

Python verwaltet Speicher automatisch und die Variablenverwaltung ist auch nicht komplizierter, als in funktionalen Sprachen.