[linux-l] LinuxScript?

[Oliver Bandel]

On Wed, 3 Apr 2002, Steffen Dettmer wrote:

> * 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.
[...]
[...]

 
> > [...]
> > > /* 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
[...]

Namespace in C?

OK, ich geb's zu, ich habe mir Dein Beispiel nur flüchtig angeschaut. :)
Aber Namespaces in C? Na hör mal. ;-)


[...]
> Ist aber OO-stil, oder eben OO-ähnlich.
> 
> Es gibt keinen "OO-stil" oder so. In Perl kann man OO sehr
> "funktional aussehend" programmieren.

Ja, so aussehend.

"Funktioinal aussehend ist nicht funktioal.
Oder ist OO-aussehen OO?

Do you know, what I mean?
 
[...]
> > 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 :)

Ich weiß, was man in Perl machen kann.


> 
> > 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?

Ja, da fehlt 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.

Ich weiß.
Aber der Unterschied zu den FPLs ist so groß, daß diese
Welten zusammenschrumoen auf Sandkorngröße...

Aus FPL-Sicht ist der Unterschied zwischen prozedural-nicht-OO
und prozedural-OO nur marginal.



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

Irgendetwas hast Du ncith verstanden.Schau Dir nochmal
ganz genau an, was FPLs können, und was die Programmierung
unterscheidet.

Dann wirst Du sehen, daß Perl gegenüber C zwar viele Vorteile
bietet, aber diese doch aus der neueren perspektive niedliche
add-on's sind.


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

Lohnt sich der Lernaufwand nicht. :)

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

Im Gegensatz zu Ocaml aber sehr.

In dem Buch dazu steht uch ein bische was zum OO
als Vergleich Ocaml vs. Java.


[...] 
> > Die meisten Sprachen gestatten sehr wohl iterative Programmierung,
> > Schleifen,
> 
> Wozu denn Schleifen, dachte, das wäre einer der
> Hauptunterschiede?

Nicht alle FPLs sind pure FPLs.

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

Man braucht schon Variablen. Aber man kann sie in FPLs
nicht nachträglich ändern -> non mutable.
Aber wenn man auch imperative Features in der Sprache hat,
kann man die natürlich nutzen.

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

Na und?
Das Wesentliche fehlt aber dennoch.

> 
> > 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?

Geht nicht.
Oder machst Du OO in ANSI-C?


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

Macht 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 :)

Nicht Schrott, aber Unisnn. ;-)

> In C kann man ja auch sauber arbeiten. Machen eben nur nicht
> alle...

Du argumentierst so, als wenn ich sagen würde: Auch in C hat man
Typprüfung, wozu brauche ich C++?


Warum kann man in C++/Java casten?
Das ist doch Vergewaltigung von Typensystemen.
Dann kann ich auch gleich C nehmen und alle Pointer
als void* deklarieren. Dann spare ich mir die
Casterei. :)


> 
> > - ...diverse weitere Vorteile, u.a. auch aus den Sachen,
> >   die mit dem pattern-Matching machbar sind,
> 
> Kann Perl auch als Sprachelement, C als Funktion...

Nein. Pattern Matching ist anders gemeint und viel
umfassender.

Das Haskell-Beispiel war mit Pattern-Matching auf
die Eingangsdaten (Argumente der Fkt.).


> 
> >   mit den Klassensystemen bzw. Modulsystemen, die mit den
> >   Sprachen einherkommen,
> 
> C, C++ und alle anderen haben sowas auch

Nicht so leistungsfähig.
Bei C geht das ja quasi nur über Files und static-Funktionen.

Kein Vergleich.

> 
> >    mit abstrakten Datentypen,
> 
> Na gut, C nu nicht, aber C++, und Perl fast :)

Nein. Murks.

Wie soll man sowas in C++/Perl machen?
Habe noich keinen Code gesehen, der Vergleichbar mit
dem ist, was man bei den FPLs vorfindet.
Bei FPLs kannst Du fast die Syntaxdiagramme 1:1
abtippern und hast schon Dein Programm fertig.

Wie machst Du das, wenn Du eine BNF hast in C++ oder Perl
oder Java?




> 
> > 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?

Wieviel C-Code brauchst Du, um ein Perl-Pattern-Matching
in C zu implementieren?
jaja, es gibt Libraries... aber eben sind Libraries
nicht die Sprache selbst... und selbst mit Libs
wird's in perl schneller gehen.

So ungefähr ist das dann da auch.

Die Vorteile der FPLs kommen zum Tragen, wenn es um komplexe
Applikationen geht.
Ein par ad-hoc-Filter schreibt man vielleicht weiterhin
in Perl. Aber wenn's an aufwendigeres geht...

> 
> > 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?!

Nein.
Ist nur eine kleine Intro.
Perl kommt ausserdem nicht gleichzeitig mit Interpreter,
Bytecode-Compiler und Nativecode-Compiler daher.

Schau doch mal in den Buchtext:


===>> http://caml.inria.fr/oreilly-book/

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

Python kenne ich nicht im Detail. Sieht aber recht
durchdacht aus, die Sache.


[...]
> > 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.

Ein Rückgabewert in C gehört dem, der ihn empfängt.
Derjenige kann ihn ändern.
Auch in C kann man Daten kapseln. Greift man eben
nicht direkt auf die Daten zu, sondern hat Funlktionen,
die einem Werte zurückgeben. So what?

Den Wert, den man bekommt, kann man aber nach belieben ändern.
Bei FPLs geht das nicht. Die Var. behalten ihren Wert.

[...]
>> > 
> > (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.

Du matchst nicht auf Zeichenketten, sondenr auf die
übergebenen Argumente.

Habe keine Zeit, die Mail noch weiter auszudehnen,
weil ich gleich zum Arzt muß (Weisheitszähne rausnehmen lassen...).


[...] 
> > 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!


Mannjahre java spart man, nimmt man OCAML. :)

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

Siehe URL oben.

Frage ist, wie komplex die Probelem sind, die man lösen will.


> 
> > 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ß.

Nö.
Steht da was über die Implementierung in der Syntax drin?


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

No.


> 
> 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:

referenzen brauchst Du dann abrer nicht mehr....

=> Frickel.

[...]
> > Oder mit der Funktion map kann man eine Funktion auf
> > die Listenelemente anwenden, ....
> 
> Heißt in Perl auch map :)

No. Perl's map is a draft. :-)


> 
> > Diese Möglichkeit ist echt wat feinet. :)
> 
> Ja, erinnert mich sehr an Perl.

Ist'a aber nicht.

[...]
> > 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.

Die Leute, die ichmeine, kennen's aber sehr gut.


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

Geht.

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

Na eben. Also deswegen kann man FPLs auch nicht richtig
emulieren.

Was Du für OO reklamierst, gilt auch für FPLs:
Man kann's nicht wirklich "mal eben" nachbauen.

So, jetzt muß ich los.

Ciao,
   Oliver