[linux-l] LinuxScript?

[Steffen Dettmer]

* Oliver Bandel wrote on Mon, Apr 01, 2002 at 19:55 +0200:
> > Na ja, kommt auf das Problem an. Ein "ist-ein" schreit nach
> > Vererbung, ein "hat-ein" schreit nach Aggregation...
> 
> Aber wer auf "OO" immer nur "Vererbung" antwortet,
> ist vermutlich schon zu sehr eingenebelt.

Ist aber doch auch das Hauptkriterium. Zwar nicht hinreichend,
aber notwendig. Und für Polymorphie ist Vererbung auch notwendig.
Also ist Vererbung schon der Punkt Nr.2 (gleich nach
"benutzerdefinierter Datentyp").

 [...] 
> > Kommt vielleicht noch. Java hat ja damit ganz gut
> > angefagen - hier gibt's sehr umfangreiche Bibliotheken. Das hat
> > schon so seine Vorteile.
> 
> Kaffee ist zum Trinken da, nicht zum Programmieren.

Was soll das heißen? Ich find Java nicht schlecht. Nicht
schlechter als der andere Kram :)

> > Objektorientierung überhaupt nicht wiederfindet. Es sieht zwar
> > vielleicht so aus, weil da "class" steht, aber ohne Vererbung und
> > Polymorphie ist es eben *nicht* OO. 
> 
> Ich weiß immer noch nicht, auf was Du da hinaus wolltest.

Man kann Dinge haben, die viele Objekte nennen würden; aber wenn
man keine Vererbung hat, ist's nicht OO, sondern vielleicht ein
Modul. Ein Modul (im theoretischen Sinn) plus Vererbung plus
Polymorhpie ist ja gleich Klasse.

> > /* Headerfile */
> > int getDirectoryFiles(void);
> > 
> > /* C File */
> > /* typedef struct Directory {...} */
> > static Directory dir_;
> > 
> > int getDirectoryFiles(void)
> > {
> > 	return dir_.fileCount;
> 
> Häh?
> Wie kommt das da rein?

Ist doch völlig unerheblich. Irgentwas setzt das vielleicht.
Egal. Ist ja ein getter.

> > }
> > 
> > static void somePrivateMethod(void)
> > {
> > 	//cannot be called from outside
> > }
> 
> Sieht übrigens nicht nach ANSI-C aus.

Denke, Du weißt, was "//" macht :)

> > zwischen "public" und "private" Methoden). Man kann dann das
> > Directory fragen, wieviele Files es hat.
> 
> Du fragst das Directory natürlich nicht, sondern Du setzt
> eine Funktion an, um den Wert zu ermitteln....

Eben, genau wie bei einem Objekt. Das sieht man sehr schön in
Perl, weil man hier beide Notationen beliebig wechseln kann; es
ist natürlich immer das selbe. Man ruft immer nur was auf. Das
"OO dran" ist, wenn die Funktion weiß, zu welcher Instanz sie
gehört, ohne das man ihr das explizit sagt. Und das geht auch
theoretisch mit einem struct, bißchen viel Handarbeit in C. Wird
dann bloß umständlich ohne Ende. Aber geht. 

Soll heißen: die Grenze ist ziemlich "fließend". Nur macht "OO
halbe" oft wenig Sinn, also macht man es oft ganz oder lieber ein
Modul.

> > Zusätzlich kann man
> > natürlich statt einem einzigen "static Directory dir_;" auch ne
> 
> wat'n für'n "dir_" ?

Na, ein static Directory *dir_. Muß ja kein Zeiger sein, ist doch
hier völlig egal, wo das Teil lebt. Das Beispiel war hier sicher
nicht konsistent, aber ist doch völlig egal. Jedenfalls lebt
irgentwo ein Ding, was dir_ heißt und ein Directory ist.

> [...]
> > /* C File */
> > Directory *new(void)
> > {
> > 	Directory *this = malloc (sizeof(Directory));
> > 	this->memberValue = "inital values...";
> > 	return (this);
> > }
> 
> Ach sowas hast Du vor...
> 
> Naja, das Teil würde ich lieber new_directory nennen,
> sonst fälltst Du da evtl. auf die Nase, wenn Du denkst,
> das wäre ein allgemeines new. :)

Man! Deshlab liegt dieses new doch im Directory-Namespace. Sieht
man auch in Perl schön. new ist genau das, was Constructor in C
ist, nur das der eben nicht per Konvention vom operator new
aufgerufen wird, sondern das man es direkt macht - was auch viel
logischer ist. Ich finde, man hätte den Constructor problemlos
new nennen können, aber dann wäre machem aufgestoßen, das dieser
bei Stackvariablen dann doch wieder impliziet
(diese == defaultconstructor) aufgerufen wird. Also auch nicht so
ideal. Das Dilemma hat ja Perl ganz nett gelöst. Aber egal.

> [...]
> > Dann kann man schreiben:
> > Directory *dir = newDirectory();
> > getDirectoryFiles(dir);
> > 
> > Man kann auch noch Funktionspointer in den Struct miteinbauen,
> > dann kann man schreiben:
> > 
> > int count = dir->getFiles();
> > 
> > Alles C. Sieht zwar schon für manche nach OO aus, ist es aber
> > nicht.
> 
> Ist aber OO-stil, oder eben OO-ähnlich.

Es gibt keinen "OO-stil" oder so. In Perl kann man OO sehr
"funktional aussehend" programmieren. OO kennzeichnet sich nun
mal nicht durch Synatx, sondern durch ben. def. Datentyp,
Vererbung und Polymorphie. Und das man "die Funktionen am Objekt"
aufruft, und nicht "einfach so", ist notwendig, damit Polymorphie
funktionieren kann. Also, Polymorphie funktioniert natürlich
auch, wenn die Funktion irgentwie anders weiß, zu welches Instanz
es gehört (z.B. wieder Perl).

> OK, man kann auch noch mehr Zeugs dazu implementieren
> und echtes OO zusammen bauen.

Du kriegst aber so ohne weiteres keine Vererbung hin. Du kannst
natürlich C "erweitern", z.B. mit schlauen Marcos vielleicht, die
dann einem Struct weiteres hinzufügen. Aber selbst dann kannst Du
keine Zeiger auf "Basisklassen" haben, weil für den Compiler sind
das ja keine. Natürlich kann man das über void* casten oder so,
könnte in C sogar gehen, und auch so Funktionen aufrufen. Dann
kriegt man aber wieder schlecht Polymorhie hin, wenn es kann ja
sein, daß eine Funktion nicht überschrieben wurde etc. Also muß
man die VMT (virtual method table) auch noch implementieren, also
alle Funktionen über einen Verteiler schicken, und hier mit
switch oder anderen bösen Dinge die richtige laut VMT auswählen.
Na ja, mit gaaaanz viel Aufwand kriegt man was hin, was sich OO
verhält, klar, C++ wird ja letzendlich auch nur Assembler, aber
davon merkt man dann nix mehr, wenn man es benutzen möchte.

> Und dadrauf aufbauend dann eine Scriptsprache schreibend könnte
> man z.B. eben zu jenem AppleScript gelangen (oder LinuxScript?).

Oder man kommt eben zu Perl.

> [...]
> > Sieht doch wirklich schon sehr nach OO aus - ist es aber trozdem
> > nicht. Und so wird es ja in C auch oft gemacht. Vielleicht nicht
> > mit Funktionszeigern, aber es wird gemacht.
> 
> Mit Funktionszeigern usw. kommt man dann aber erst in die
> interessanteren Regionen. :-)

Mag sein, hab sowas aber sehr selten in dieser Form gesehen.

> So, jetzt mehren wir uns aber doch ganz schön aus...

:)

> > Gibt's doch: Perl Modules, ACE, Java,... Die machen ja im Prinzip
> > nix anderes; nur das nur Perl eine Scriptsprache ist.
> 
> Aber Du hastr den entscheidenden unterschied in der
> Syntax nicht gesehen.

Na ja, mir war die immer ziemlich egal, muß man eh lernen. Perl
z.B. ist schon ziemlich effektiv in allen diesen Punkten, ist
halt verdammt lange entwickelt und verbessert worden, merkt man
schon. Hat alles seinen Grund, soll das heißen :)

> Perl-Programmierung ist größtenteils prozedural; man
> kann auch OO etwas beimengen.

"beimengen" ist untertrieben. Man kann sehr schön mit Packages
usw. arbeiten. Finde ich wirklich gut gemacht. Vor allem erkennt
man bei Perl wirklich, wie die "fließende Grenze" zwischen Modul
und Objekt/Klasse aussieht. Man kann sogar dynamisch zur Laufzeit
wechseln und weiß ich was. Es ist der Hammer, was da geht :)

> Richtig schnuckelig wirds aber erst mit funktionaler
> programmierung; da ist mit Perl Schicht.

Warum eigentlich? Man kann Funktionen aufrufen. Die können Listen
kriegen, oder sonstwas-Referenzen. Wenn man partou keine
Schleifen und andere schöne Sachen benutzt, kann man doch
funktional programmieren, oder fehlt da was?

> > Na ja, ich weiß nicht, warum? Es geht ja genau so in z.B. Perl,
> > nur das eben die Syntax anders ist.
> 
> Nein. Ich kenne Perl recht gut. Letztlich ist es ein enhanced C
> plus etwas OO.

Dann kennst Du Perl wohl nicht so gut. Natürlich kann man in Perl
so schreiben, daß es wie C aussieht. Aber auch neben OO gibt es
viele Unterschiede, z.b. Listen und hashes als *Datentypen*, Die
vielen netten Operatoren, Referenzen und Garbage collection,
dynamische Codeerzeugung zur Laufzeit, dynamisches Code
nachladen/überschreiben zur Laufzeit usw. Dazwischen liegen
WELTEN. Java kann schon etliche dieser Spielereien, Reflection
API und sowas, aber nicht so schön, finde ich. 

> > Im Prinzip das gleiche.
> 
> Ja, Perl und C sind im Prinzip das Gleiche.
> Das ist es ja, was ich meine...

Irgentwas hast Du nicht verstanden ;)

> Letztlich ist auch C und C++ sehr ähnlich.
> Das bischen OO macht den Kohl nur unbedeutend fetter.

Na ja, wenn man von weit genug weg hinguckt, ist jede
Programmiersprache ähnlich, wie Dir meine Freundin vermutlich
bestätigen würde :)

> [...]
> > > Also, zumindest wenn man nicht immer wieder das Rad in C neu
> > > erfinden will, also eher high-level programming machen will,
> > > bietet sich eine ergänzende Schicht an.
> > 
> > Na, warum denn C in Unix?
> 
> Warum nicht?

Weil es C++ gibt.

> > Da kann man meistens C++ nehmen, gibt's ja für
> > Unix :).
> 
> Warum denn C++?
> Ist ja umständlich, unflexibel, ...

Im Gegensatz zu C und Assembler eher weniger :)

> > Und für C++ gibt's ja dann ACE usw.
> 
> ACE?
> Was'n das?
> Wieder irgend wo ein Hype-Zeugs, das im nächsten Jahr
> wieder vergessen ist - und viele Firmenpleiten begleitet
> (eingeleitet?) hat? :->

Wenn Du noch nix davon gehört hast (aber vermutlich die eine oder
andere Zeitschrift und Newsgroup liest), wird's wohl kein Hype
sein :) War nur'n Beispiel für ne Lib.

> Die meisten Sprachen gestatten sehr wohl iterative Programmierung,
> Schleifen,

Wozu denn Schleifen, dachte, das wäre einer der
Hauptunterschiede?

> Variablen (aber die sind nur lokal - das ist ein
> sehr wichtiges Prinzip dabei => keine Seiteneffekte).

Na ja, so als "Hilfsvariablen" vermutlich nicht unbedingt nötig,
sondern nur für den Programmierer, damit es schöner und einfacher
aussieht.

> > Aber eigentlich müßte man dann ja auch in C funktional
> > programmieren können: eben, wenn man keine Schleifen und
> > Variablen verwendet.
> 
> Nein. Nur weil Du das weglässt, ist Deine Programmierung
> noch nicht funktional.
> Schon globale Variablen schmeissen alles über den Haufen.

Die wollte ich doch weglassen :)

> Und wie schaut's mit Funktionen als Parameter und Rückgabewerten
> aus?
> Geht nicht. In C muß man mit Pointern rum frickeln.

Geht also doch. Ist sicher nicht ideal. Geht in Perl sicher
besser. Aber geht es nun ode rgar nicht?

> Wenn man Standardkonform programmieren will, sind Pointer
> auf Funktionen unterschiedlicher Prototypen auch nicht
> untereinander "verlustfrei" konvertierbar.

Ja klar, wenn sie sich hinsichtlich von Typen unterscheiden.
Müßte doch bei funktionaler Programmierung ähnlich sein? Wenn ich
ne Funktion auf einer Liste habe, kann ich da doch keine Zahl
angeben, oder? Macht doch keinen Sinn.

> > Aber bringt das was? Ich meine, hat das
> > Vorteile?
> 
> - besser lesbarerer/schreibbarerer Code
> - keine Probleme mit Seiteneffekten
> - der Code ist gut wartbar

Das muß ja eh vom Programmierer kommen. Mit genügend krimineller
Energie kann man sicherlich auch funktional Schrott schreiben :)
In C kann man ja auch sauber arbeiten. Machen eben nur nicht
alle...

> - ...diverse weitere Vorteile, u.a. auch aus den Sachen,
>   die mit dem pattern-Matching machbar sind,

Kann Perl auch als Sprachelement, C als Funktion...

>   mit den Klassensystemen bzw. Modulsystemen, die mit den
>   Sprachen einherkommen,

C, C++ und alle anderen haben sowas auch

>    mit abstrakten Datentypen,

Na gut, C nu nicht, aber C++, und Perl fast :)

> Wenn man dreitausend Zeilen C-Code oder 2000 Zeilen C++-Code
> oder Perl-Code gegen vielleicht 120 Zeilen OCaml-/Haskell-/LISP-Code
> austauscht, dann weiß man, woran man ist. :-)

Das heißt ja: Man kann ein 2000 Zeilen Perl Programm nicht
sinnvoll kürzen, aber äquvivalent in 120 Zeilen funktionalem Code
ausdrücken. Ist das wirklich so?

> s.o., oder schau doch gleich mal hier rein, damit Du weißt, wieso
> ich denke, daß man - wenn man C++ noch nicht kann, es auch
> lieber nicht lernen sollte und Zeit lieber dazu aufwendet,
> was vernünftiges zu tun, nämlich Ocaml zu lernen:
> 
>    http://caml.inria.fr/FAQ/stephan.html

Wo ist da nun der Hammer?! Geht doch so in Perl auch ziemlich
ähnlich?!

> > > Welche Leute kennst Du denn?
> > > C, C++ Perl, Python?
> > 
> > Python auch nicht. 
> 
> Schade. Ich kenn's auch nicht näher. scheint aber, soweit
> ich's mal eines flüchtigen Blickes beäugt habe, schon
> ziemlich schnuckelig zu sein. :-)

Kann mir nicht vorstellen, daß es sich ansatzweise mit Perl
messen kann.

> Viel OO und guten modularen Aufbau soll's haben.
> (Und OO da konsequenter als bei Perl).

Was ist bei Perl nicht "konsequent"?

> > Ja, der Aufrufer hat hier die "Macht". Er kann den return-Value
> > überschreiben
> 
> Auch in OO-Sprachen hat man die Macht die return-Value
> zu überschreiben.

Man, sorry, aber ich dachte, Du siehst, was ich meine. Wenn ich
ein struct-Pointer returne, kann der Aufrufer diesen Struct
manipulieren und damit gibt es also keine Datenkapselung.

> > (ist ja kein "struct dirent *const readdir"), er
> > muß *directory beschaffen etc.
> 
> Das wäre ja auch noch schöner, wenn die Rteurnvalue
> ein const wäre.

Ja, sag ich ja, ein "Directory *const dir". Aber dann kann man
immer noch lesen. Also immernoch keine Kaspelung.

> Dann bräuchte ich ja das Programm nicht mehr zu starten, wenn
> ich schon vorher weiß, was raus kommt. Guck ich eben nach, wie
> die Konstante definiert ist. :-)

Hum?! Was war das jetzt? Die Funktion, die ein const returned,
bzw. das Modul, kann es ja ändern. Es ist nur eine elementare
Forderung, daß sowas eben nur dort und nirgentwo anders geändert
werden kann - und das auch nur ausgewählte Sachen gelesen werden
können. Da ist Java mit den Interfaces wirklich ein guten Schritt
vorraus. Na ja.

> Daß man dem Objekt nicht die Inhalte überschreiben darf,
> sehe ich ja ein. Aber daß ich die vom Objekt erhaltenen
> Daten nicht nach meinem Belieben ändern darf, das ist
> - mit Verlaub gesagt - recht eigensinnig, ja diktatorisch.

Nein, eine elementare Forderung des OO. Und wenn Du ein bißchen
drüber nachdenkst, erkennst Du, warum. Wenn ich z.b. ein member
habe, der fileCount_ heißt, aber von außen nicht sichtbar ist,
kann ich den jederzeit ändern oder umbenennen, alle, die das
benutzen, merken davon nix. Ich kann also die Implementierung
ändern, solange das Interface gleich bleibt. Geht in C++ leider
bei Klassen nur eingeschränkt, weil ich die private Member leider
in's Headerfile schreiben muß, na ja, nicht ideal, aber geht.

> Oder, man könnte auch sagen: Schwachsinnig.

Kurzsichtig.

> Oder willst Du nun doch funktional programmieren?
> Da gibt es keine Zuweisungen. Ist es das, was Du
> damit meinst?

Nein, ich sprach von OO. Oder auch Modulen. Module haben auch
genau diese Eigenschaft: Datenkaselung, Geheimnisprinzip. Aber
das hab ich alles schon geschrieben :)

> > Directory ist eindeutig ein Datenfluß, kein Kontrollfluß.
> > Außerdem hat readdir nicht die Fähigkeit, auf allgemeine
> > Nachrichten zu reagieren (es "ist" kein "Nachrichtenverarbeiter".
> > In java würde er also das Interface nicht implementieren, bzw. in
> > C++ nicht beerben). Also geht kein readdir.handleMessage oder
> > sowas. Könnte man aber bauen, klar.
> 
> Es soll ja auch nicht readdir, sondern das Directory befragt werden.

Ist doch das gleiche. Du rufst "readdir am Directory" auf.
Technisch/logisch/mathematisch rufst Du ein readdir auf, was aus
irgentwelchen Gründen weiß, zu welcher Instanz es gehört. Auch
wenn DU es gar nicht auf Directory aufrufst, sondern auf
irgenteiner Vater- oder Kindklasse (eben Polymorphie). Das kann
man drehen und wenden wie man will, es bleibt das gleiche. In
C++/Java schreibt man das syntaktisch "am Objekt", aber das ist
eben nur Syntax, keine Sematik oder Logik. Könnte man auch ganz
anders machen, wäre genau dsa gleiche. Siehe Perl: hier gibt's
meherere Möglichkeiten. Man kann eben in Perl beide hier
erwähnten Aufrufskonventionen benutzen - und hier sieht man, das
es wirklich das gleiche ist.

> Sende Message "readdir" an Objekt "directory".

Eine Message, also ein Kontrollfluß, sollte aber nicht zu einer
Antwort-Message führen, die die Daten enthält. Das ist
Vergewaltigung von Events. Es sollte vielleicht eine "Ich bin
fertig" Nachricht zurücksenden, und dann kann jemand über einen
Getter die Daten abholen. Das ist dann aber ein Datenfluß, klar. 

> Oder anders ausgedrückt: Rufe Methode "readdir" des Objektes
> "directory" auf.

Das ist ein bißchen was anderes. Beim Senden von Nachrichten
entscheidest Du eben nicht, ob readdir aufgerufen wird, oder
nicht, das macht der Eventhandler, und Nachrichten benutzt man
i.d.R., wenn diese verteilt werden können. Das wirkt sich dann
positiv auf multithreaded Programme aus. Dann kann nämlich
problemlos ein anderer Thread die Nachricht später bearbeiten
oder sowas. 

Das Aufrufen von oben ist wieder das Aufrufen einer Methode, die
irgentwie weiß, daß sie zu einer bestimmten Instanz des Objektes
gehört, also wie ein 

readdir (Directory *this)
{
	// "this" ist meine Instanz
}

(Dieses readdir das ist aber natürlich nicht Polymorph). Also ist
object->readdir() und readdir(object) das gleiche. Geht natürlich
nicht in C, wegen der Polymorphie usw., aber in Perl z.B.

> Btw: Was hattest Du eigentlich studiert?

Informatik. Und Du?

> > Müßte in Prolog dann auch ganz gut gehen. Ist Prolog vielleicht
> > funktional?
> 
> Nee.
> 
> Ist noch ein anderer Typ von Programmiersprache.
> Aus der Logik-Ecke.

Ja, schon klar, aber da hat man auch sowas wie Funktionen, macht
Schleifen über Rekursionen etc.

> Die genaue Bezeichnung der Gruppe von Sprachen müßte man
> nochmal einen Informatiker fragen (lernen die sowas?).

Ja, hab's nur vergessen. Dazu muß man aber auch sagen, daß sie
die Sprachen selten wirklich abgrenzen lassen. Oft ist eine - je
nach Sicht - mehereren Typs oder keines. Na ja :)

> > Quicksort war "Teile-Und-Herrsche", bis man über zwei Elemente
> > herrscht, die man ggf. austauscht, und dann sortierte man die
> > geteilten (und inzwischen sortierten) Ketten, richtig? Oder
> > verwechsel ich das schon wieder?
> 
> Häh?
> Immer diese seltsamen Metaphern... ;-)

Teile und Herrsche? Ist ein Grundprinzip...

> > > qsort (x:xs) = qsort [ y | y<-xs, y <=x] ++ [x] ++ qsort [y | y<-xs, y > x ]
> > 
> > Verstehe ich überhaupt nicht, kenn auch die Syntax überhaupt
> > nicht.
> 
> (x:xs) ist ein Pattern-match, das eine Liste in erstes Element,
> das "x" vorm Doppelpunkt und den tail der Liste 
> (das "xs" nach dem, Doppelpunkt) aufsplittet.
> Das an die Funltion übergebene Argument wird also aufgesplittet.
> Pattern match eben.

Was ist daran Pattern-Match? Ich erkenne hier nichtmal ein
pattern, daß auf irgentwas matchen könnte. Ein Pattermatch wäre
für mich
/^Eine bestimmte Zeichenkette$/
oder sowas.

> Sieht doch von der Syntax her so aus, als daß es jeden Mathematiker
> fröhlich lächeln läßt: [ y | y <- xs, y<=x ]

Also y ist Element der Liste, wenn es aus xs kommt und kleiner
als x ist?

> > Irgentwie kompakter :)
> 
> Sachickdoch. :)

Liegt hier aber nur an der Syntax, weil es komplexe
Listenoperatoren gibt. Diesen "Operator" kann man aber auch als
Perlfunktion implementieren. Würde man aber nicht machen, weil es
schneller geht. 

> Wenn Du die Sprachen nicht benutzt hast, wirst Du auch
> dieses feature nicht benutzt haben.
> Dewegen kennst Du die Vorzüge nicht. Deswegen kannst Du Deinem
> zukünftigen bröthcengeber diese nicht verklickern.

Der muß ja auch Geld verdienen! Und sortieren hab ich in der
Praxis nie programmiert, weil sowas eh immer schon fertig ist :)

> Deswegen glauben die Brötchengeber, daß in den Unis nichts
> fortschrittliches gelehrt wird.

Da haben sie aber auch Recht. Momentan braucht man meistens
effiziente Frameworks, die Verteilte Systeme abbilden usw. Das
ist ne viel höhere Stufe. Da denkt man überhaupt nicht über
elegantes Sortieren nach, sondern mehr, wie man seine Daten
sicher übers Netz bekommt und Systemausfälle ausgleichen kann
etc.

> Hättest Du es Dir näher angeschaut, hättest Du aber
> vermutlich schlechte laune, wenn Du mit C++/Java arbeitest.

Wieso, in Java und C++ gibt's schicke Frameworks mit massig
Mannjahren Entwicklungsleistung. Die möchte ich nicht
nachschreiben müssen... Schon allein so ne CORBA ORB
Implementierung ist extrem komplex... Nee, da bin ich verdammt
froh, daß ich den Kram fix und fertig kriege und benutzen kann!

> Aber eher setzen die Unis auf Windoof und C++, als daß sich
> die verbretterten Unternehmer - jammernd, daß sie keine
> Fachkräfte kriegen - mal anschauen, was sie alles verpassen....

Hab noch nie einen Kunden gefunden, den es interessiert hat,
wieviele Zeilen Code ein Sortieralgorithmus hat. Die Laufzeit ist
interessant, die Kosten etc. Und natürlich die Integration in
bestehende Systeme. Diese machen dann aber auch keine
print_string Ausgaben sondern keine (von logs abgesehen) oder
Fenster :)

> > Eine ideale
> > Programmiersprache müßte es gestatten, sozusagen "sauber zwischen
> > den Konzepten zu wechseln", wie man es gerade braucht.
> 
> Schau Dir mal OCaml an. Ist was feines.

Nach der URL von Dir fand ich es nicht schöner als Perl. Gnaz im
Gegenteil.

> Man kann z.B. mit der Funktion filter folgendes nettes machen:
> 
> filter isEven [2,3,4,5]

Ist bloß wieder wenig Performant, weil man zu viele Listen
kopieren muß. Sowas geht in Perl auch schick, aber macht man
meistens nicht, weil es bei sinnvollen Daten (so ab 10.000
Elementen) einfach zu langsam wird. Unterm Strich muß man dann
jedes Element öfter anfassen, als bei iterativer
Herangehensweise. Und wenn man die Ordnung von O(n) auf O(n^2)
erhöht, hat man einfach verloren. Das läßt sich auch nicht mehr
mit schnelleren Maschinen ausgleichen...

> filter isSorted [ [2,3,4,5],[3,4,44,7],[],[4] ]
> 
> gibt alle Listen zurück, die sortiert sind....

Ja, genau wie in Perl. Da kann man dem Sort optional auch noch
einen Vergleichsoperator (also Funktion) übergeben. Wenn man den
negierten Vergleichsoperator übergibt, wird eben rückwärts
sortiert. Man kann natürlich auch "reverse" davorschreiben (ist
nur eben wieder langsam, erst falsch zu sortieren und dann
nochmal umzudrehen). Da schreibt man dann:

sort ( 2, 3, 4, 5 )

Man kann sich ganz einfach auch ein sort machen, was Referenzen
erwartet und dann schreiben:

sort [ 2, 3, 4, 5 ]

Und man kann das rekursiv machen, und schreiben

sort [ [2,3,4,5],[3,4,44,7],[],[4] ]

und das auch isSorted nennen. Aber ich finde, es macht keinen
Sinn, Listen und Zahlen nebeneinander zu sortieren. Ist 5 größer
oder kleiner als [3, 4]? Macht keinen Sinn...

Listen untereinander zu sortieren auch nicht:
[[3, 5], [4, 4]]
was kommt zuerst? In Perl kann man es natürlich machen, wenn man
einen entsprechende Vergleichsfunktion übergibt :)

> Oder mit der Funktion map kann man eine Funktion auf
> die Listenelemente anwenden, ....

Heißt in Perl auch map :)

> Diese Möglichkeit ist echt wat feinet. :)

Ja, erinnert mich sehr an Perl.

> Also, ich kann Dir die Details nicht nennen, dazu bin ich
> in der Materie nicht tief genug. Aber wenn Du mal in
> comp.lang.functional gelegentlich mitliest, und dann
> da die Freaks loslegen, hört man immer wieder davon, wie
> kruder, unausgegorener Kack doch C++ und Java sind....

Das hört man i.d.R. von Leuten, die C++ und Java nicht kennen.
Wie bereits gesagt, die Sprache hängt vom Problem ab. Und ich
kann mir nicht vorstellen, eine interaktive GUI mit Grafiken etc.
in einer funktionalen Sprache zu machen...

> > Man *kann* das auch in C verhindern / behandeln.
> 
> Man kann auch in C OO-programmierung machen...
> ...wenn man sich das OO-System selbst zusammen baut.

Ohne Vergewaltigungen kriegt man es eben nicht hin, weil eine
Methode nie weiß, zu welcher Instanz sie gehört (das hört dann
spätenstens bei Polymorphen Geschichten auf).

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.