Code Reuse a la UNIX (was: Re: [linux-l] zsh besser mit andere Sprache)

Oliver Bandel oliver at first.in-berlin.de
Mo Okt 10 16:00:58 CEST 2005


On Mon, Oct 10, 2005 at 03:52:59AM +0200, olafBuddenhagen at gmx.net wrote:
> Hallo,
> 
> > gibt es für "convert" nicht eine API? Ist convert nicht auf
> > ImageMagick-Library basierend?
> > 
> > Kann man da nicht direkt mit arbeiten, statt den Umweg über
> > Shell-/Scripting-Sprachen zu gehen?
> 
> Klar könnte man. Aber will man das?

Irgendwer hatte gejammert, "find -exec" wäre zu langsam.
Ich selbst denke, daß das nicht stimmt, jedenfalls
meistens stimmt es nicht.

Aber in diesem Zusammenhang habe ich das mit der API erst
erwähnt.


> 
> Der Aufruf von anderen Prozessen ist *die* klassische UNIX-Methode für
> Code Reuse -- leider größtenteils in Vergessenheit geraten.

Naja, ich finde das ja auch sinnvoll und mache es oft mit Pipe & Co,
mir die Arbeit zu erleichtern.



> 
> Klar ist es nicht immer ganz sauber, und generell mit einem gewissen
> Overhead verbunden. Neben einigen anderen Sachen hat es aber vor allem
> einen sehr entscheidenden Vorteil gegenüber Libraries: Es ist
> *wesentlich* zugänglicher.


Stimmt schon.
Ich bin da auch dieser meinung, nur weil da wegen Performance-Magel
gejammert wurde, habe ich das dann mit der Lib erwähnt.

Also ist mein API-Ansatz ja mit ner anderen Voraussetzung
her entwickelt worden.

Ich finde sogar, daß man das Konzept, das find benutzt
viel intensiver nutzen sollte, denn es ist ein Ansatz
wie er in funktionalen Sprachen genutzt wird.

find . -exec <script>

ist quasi ein Tool, das ein andere Tool als Argument übergeben bekommt,
so, wie man in funktionalen Sprachen Funktionen an Funktionen übergeben
kann.

Es kann aber wohl sein, daß find das alles via Shell-Aufruf macht
und dadurch overhead erzeugt, statt direkt mit exec...?!

Weiß nicht, müsste man mal in den Code schauen.
Klar, da sind dann intern Daten, die hin und her geschaufelt werden,
die bei direkter Programmierung wohl so nicht entstünden.
Aber man kann da auch Parameter an das aufgerufene Tool übergeben
und das macht es sehr flexibel.

Zu dem Thema Nutzung von Tools, die Tools als Parameter bekommen,
habe ich mal ein kleines Paper geschrieben und es "Using Functional
Features on the Command Shell" genannt, aber es sind nur 4 Seiten geworden
und ich hatte nur wenige Beispiele genommen. Wollte das noch ausbauen,
aber ich hatte in der letzten Zeit etwas andere Sachen um die Ohren.
Gerne hätte ich auch noch Beispiele anderer Leute mit aufgenommen,
oder ich muß mir selbst nochmal was dazu ausdenken.



[...]
> Leider habe ich bisher nichts was die Bedeutung dieses Grundsatzes
> konkret im Zusammenhang mit Code Reuse behandelt.
[...]

Vielleicht weil es entweder so offensichtlich ist, daß es niemand
bemerkt/sieht, oder weil es eigentlich nicht Code-Reuse ist,
sondern Executable-Reuse, was ja nur ein indirektes Code-Reuse ist.

Aber zum Beispiel gerade jene, die über GPL im kommerziellen
Feld jammern, die könnten doch den Unix-Ansatz genau dazu
benutzen, um doch GPL-Tools in nicht-GPL-SW zu "re-usen",
indem sie die GPL-Tools via exec() oder system() aufrufen,
statt mit den APIs zu verlinken.

Aber diese Konzepte sind vielen (weil von anderem OS her kommend)
kommerziell-Programm-Programmierern garnicht bekannt... (?!)


[...]
> Auch nicht, warum das klassische UNIX-Prinzip bei den meisten heutigen
> Anwendungen versagt,

Weil GUIs bisher meist auf andere Weise gesteuert werden.
Man kann GUIs i.A. nicht via Pipe betreiben, weil der OO-Ansatz
und das gesamte Konzept, das genutzt wird, nicht die Ausgaben
von Pipes nutzen (können).
Bei Ansätzen a la HTML bzw. Kommandosprachen für GUIs im Allgemeinen
sollte dies aber möglich sein.
Wenn man ein HTML-Dokument in einen Browser pipet, der von stdin
liest und die Sachen dann ver-GUI-t, hätte man so ein Konzept.

Aber dies wird i.A. nicht genutzt.

Das heisst, man nutzt Zustände von z.B. Objekten, statt einer
Beschreibungssprache.
Dann entsteht das Problem, die Zustände der GUI an andere
Programme weiter zu geben. Manche Sprachen unterstützen das
einigermassen, aber richtig prickelnd scheint das alles nicht zu laufen.

Würde man die GUIs mit einer Sprache beschreiben - schon von Anfang an,
statt erst, wenn man Zustände von Objekten serialisieren will -,
dann hätte man dieses serialisierungsproblem schon deshalb nicht,
weil man von Anfang an es erst garnicht aufkommen lässt.

Dann kann man auch eine textdatei nehmen in ein spezielles Progrämmchen
pipen und bekommt als Ergebnis eine lauffähige GUI.


> und wie man dem mit neuen Konzepten (in Hurd oder
> Plan9) abhelfen kann. Kommt zweifelsfrei alles noch, früher oder
> später...


...mal kieken.


> 
> Das obige Beispiel ist jedoch ein ganz klassisches, bei dem die
> traditionelle UNIX-Methode wunderbar funktioniert. Hier mit Libraries
> anzufangen wäre IMHO einfach nur dumm.

Kommt eben drauf an, ob man wegen der Performance-Probleme unbedingt
das ganze noch mal speziell auf der API basierend zusammen bauen will.

IMHO ist ja auch "find -exec" nicht so langsam, daß man das
nicht nutzen können sollte; jedenfalls wenn man annimmt, daß
das Script, an dem sich diese Diskussion hier entfachte,
nicht GB-weise ganze Platten abgrast und hunderttausende von Files
bearbeiten soll, sondern daß es ein paar Files aus dem `pwd`
nimmt und die bearbeitet - eine Sache, die vermutlich in 95 % aller
Anwednungsfälle vorliegt (und 4% viell. noch Subdirectories unterhalb
des `pwd` nutzt; viell. noch 1%, wo es um grosse Dateibäume geht...).

Ciao,
   Oliver



Mehr Informationen über die Mailingliste linux-l