Exotische Prog.Sprachen

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.