[linux-l] LinuxScript?

[Oliver Bandel]

Moin,


On Sun, 31 Mar 2002, Steffen Dettmer wrote:

> * Oliver Bandel wrote on Sun, Mar 31, 2002 at 21:29 +0200:
> > > machen solche Ansätze überhaupt Sinn unter Unix? Ich meine, ein
> > > Filesystem ist ja eben kein Object und so, was soll man da an
> > > Aktionen anheften können. Kann mir nicht vorstellen, das sowas
> > > elegant geht.
> > 
> > Die systemnahe Programmierung unter Unix/Linux ist sehr wohl
> > OO-ähnlich.
> 
> Natürlich kann man mit Gewalt jedem funktionalem
> Objektorientierung anhängen. 

Das liegt mir fern.
Finde den OO-Fanatismus selber reichlich nervig.
I like ANSI-C. :-)


> 
> > Aber den Filetyp (reg. File, Link, Directory) als Eigenschaft
> > eines Objektes im FS zu betrachten liegt doch nahe, oder?
> 
> Da die Eigenschaften sehr ähnlich sind, würde man hier jedoch nur
> eine ziemlich flache Vererbungshierachie hinkriegen, kann mir
> nicht vorstellen, daß sowas sehr viel bringt. 

Vererbung ist zwar das, was alle immer gleich mit OO verbinden.
Aber in der Regel ist Vererbung auch das, was am meisten
Probleme mit sich bringt (zumindest, wenn man sie dogmatisch
wirklich überall einsetzen will). Zu OO gehört mehr als nur Vererbung,
leider wird immer, wenn man OO anführt, auch quasi reflexartig
an Vererbung gedacht.
Aggregation etc. ist aber oftmals sinnvoller als Vererbungs-Fanatismus,
der aber leider oftmals bis zum Erbrechen als Dogma durchgezogen
wird - kommt wohl im Selektionsprozess der Jobsuche gut an.


> 
> Natürlich kann man sockets von files ableiten und die
> Socket-Eigenschaften hinzufügen. Aber in der Praxis braucht man
> sowas eher selten.

Tja, man sollte eben nicht immer gleich alles voneinander
ableiten/vererben wollen... :)

> Na ja, ich gebe jedoch zu, sogar selbst sowas
> schon gebaut zu haben :)

So, so... ;-)

> 
> > Ebenso könnte man auch das Objekt Prozess nach dem pwd/cwd (getcwd()),
> > seiner ID, etc. befragen.
> 
> Sicherlich die Instanz eines Prozesses. Aber macht erst wirklich
> Sinn, wenn es dann "Kinder" gibt, die spezielle Eigenschaften
> haben, die jedoch nicht immer interessieren, so daß man
> beispielsweise Polymorphie ausnutzen könnte...

Wie meinen?


> 
> > Im FS hat sowohl ein File, als auch ein FIFO oder ein Directory
> > einen Inhalt, einen Namen, einen ort, wo man es finden kann,
> > und weitere Eigenschaften.
> 
> Eigenschaften zu haben, ist kein hinreichendes Kriterium für
> Objekt/Klassenkandidaten, finde ich.

Sage ja garnicht, daß das hinreichend ist.
Finde es dennoch schnuckelig, wenn ich das Directory
fragen kann, wieviele Files es hat, oder wenn ich
die Files fragen kann, ob sie schreibgeschützt sind...

Ich sage ja nicht, daß man das gesamte drunter liegende System
neu schreiben soll. Eine weitere Schicht/Sprache/Scriptingmöglichkeit
wäre aber was feines.
Also nicht alles umkrempeln, sondern was oben drauf stülpen.


> Eigenschaften kann man auch
> sehr gut über klassische Datentypen handhaben, also ein C-Struct,
> dessen Instanz in einem Modul lebt. Natürlich ist sowas technisch
> gesehen ziemlich genau eine Klasse. Ich meine ja nur, es gibt
> hier nicht unbedingt notwendigerweise einen Bedarf.

Meine ich ja auch nicht, daß es Bedarf gibt...
aber vielleicht Bedürfnis? ;-)

 (Aus der BWL-Vorlesung weiß man noch: Bedarf = Bedürfnis + Kaufkraft) :)

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.


> 
> > geworden (funktional ist evtl. mißverständlich, da das oft auch
> 
> Meinst Du wirklich funktional oder prozedural?

Ich meine wirklich funktional.

Prozedural ist's, was man in C macht. Funktional ist's, wie
man in Scheme/Haskell/... macht.
OCaml btw. ist prozedural, funktional und OO. Wird Zeit, daß
O'Reilly endlich mal die englische Fassung des Ocaml-Buches
herausgibt.

(Ruby soll wohl auch - und mittlerweile auch Python - funktionales
 Programmieren ermöglichen. Ein Grund, sich diese Sprachen vielleicht
 doch mal anzuschauen :))


> 
> > fälschlicherweise benutzt wird für das, was man in C und Co. so
> > verbricht; ich denke da eher an Scheme, Haskell, OCaml etc.).
> 
> Kenn die Leute leider nicht.

Welche Leute kennst Du denn?
C, C++ Perl, Python?


> Aber Du hast völlig Recht: man muß
> je nach Problem die Lösungsstrategie wählen, und nicht behaupten,
> irgenteine sei die Beste.
> 
> > Aber OO in Massen hat noch niemandem geschadet, 
> 

Scheiss neue deutsche Rechtschreibung.
Ich meinte in Maßen, also im Sinne von maßvoll.
Massenweise hat OO bestimmt sehr wohl schon Uneil angerichtet. :)

> Doch, hab schon viele C++-Klassen gesehen, die hatten überhaupt
> nix mit OO zu tun usw.

:)

> Das ist dann meist mehr verwirrend und
> ärgerlich.

Dahinter sind dann die Leute zu fineden, die bei Stellenangeboten sagen,
daß sie C++ können, woraufhin der Personal-Fuzzi denkt,
der Bewerber habe Peilung von OO.
Und auf OO hin angesprochen kommt bestimmt das Stichwort
Vererbung, und alle sind sich einig darüber, daß man
wie füreinander geschaffen ist...  ;-)

Aber vielleicht waren das ja auch Wrapper für "vererbten"/historischen
(legacy) Code...


> Sinnvolle OO Abstraktion ist eine Kunst,

Gutes Programmieren ist auch prozedural eine Kunst.
Wie bei jeder kunst: Man lernt nie aus (und genau das ist
ja die Kunst daran!)


> aber ein
> bißchen was sinnvolles sollte man schon machen, wenn man OO
> benutzt :)
> 
> > ...und Unix ist von der Programierung her schon recht
> > OO-ähnlich.
> 
> Finde ich gar nicht. Ich finde eher, daß die Daten, die von
> Systemfunktionen verarbeitet werden, nicht zu den Verarbeitern
> sondern den Aufrufer gehören; beim Kernel ist das natürlich bei
> vielen Funktionen nun gerade wieder nicht so, aber spätestens bei
> der libc - find ich.

Naja, also z.B. ein

struct dirent * readdir( DIR * directory )

Liefert Dir die Einträge des Direktory nacheinander
zurück.
Sind die Inhalte eines Directory etwa die Eigenschaften
des Aufrufers?

Man könnte auch sagen: sende die Message readdir an das
Objekt directory.

Naja, könnte man noch lange drüber philosophieren.
Ist dann letztlich eine Sache der Betrachtung.

Wie gesagt, will ich ja nicht das System und die libc
verschmähen, sondern fände ein add-on ganz nett.


(Wobei OO nicht mein Hauptkriterium ist, das hatte ich
aber schon erwähnt.)


> 
> > ähnliche Syntax erfreut. Ob's tatsächlich eine funktionale
> > Sprche ist, muß ich mal genauer anschauen; sieht jedenfalls
> > auf den ersten Blick schon etwas danach aus.
> 
> Ich hab jetzt nicht ansatzweise die Definition im Kopf, kann mich
> nur noch aus dem Studium erinnern, daß sowas funktional
> aussehendes prozedural heiß, und funktional irgentwas komisches
> war, was ich gleich wieder vergessen konnte - IIRC.

Ja, prozedural nennt man das typische C-geprogrammiere.
Funktional sind Sachen wie in Haskell, hier z.B. Quicksort
in Haskell programmiert:

qsort :: [Int] -> [Int]
qsort [] = []
qsort (x:xs) = qsort [ y | y<-xs, y <=x] ++ [x] ++ qsort [y | y<-xs, y > x ]


Sieht bedeutend besser aus, als Quicksort in C. :)

Das schnuckeligste an FPLs sind die higher-order functions.
Mal eben eine Funktion als Argument übergeben und als returnvalue
zurückgeben (wohlgemerkt die Funktionen selbst, nicht irgendwelche
Pointer-Fummeleien...).




> Wäre mal
> interessant, wenn mal jemand kurz die Unterschiede hier umreißen
> könnte. Zwar OT, aber interessant :)

Bei der funktionalen Programmierung programmiert man so,
wie man es aus der Mathematik kennt: Man hat eine Funktion
mit ihren Parametern (Input) und bekommt als Output
ein Ergebnis. Es ist völlig unerheblich, ob die Argumente
und returnvalues nun Variablen im klassischen Sinne sind,
oder ob es Funktionen selbst sind. Man kann also Funktionen
schreiben, die Funktionen zurückliefern und diese kann man
dann als Argumente an andere Funktionen übergeben.
Damit kann man echt feine Sachen machen. man kommt dann nämlich
endlich mal dazu, sich darum zu kümmern, was man programmieren
will. :-)

Man arbeitet in funktionaler Programmierung ohne Seiteneffekte,
das heisst, es kann einem nichts auf die Füsse fallen, was man
evtl. vergessen haben könnte.
Coredumps kann es prinzipiell nicht geben. (Sie treten höchstens
auf, wenn die Implementierung selbst nicht ok ist - die Sprache selbst
ist ja oftmals noch in C geschrieben => da geht schon mal was schief...
aber ist die Implementierung sauber, kann man keine Coredumps
durch dumme Programmierung hervorrufen. In C kann man das mit einem
Einzeiler (sofern's ulimit nicht auf 0 gestzt ist...).).


Ciao,
   Oliver