[linux-l] Trennung von "readline" und Interpreter im Unix-Stil

Steffen Dettmer steffen at dett.de
Mi Apr 11 19:21:31 CEST 2007


* Volker Grabsch wrote on Thu, Apr 05, 2007 at 21:32 +0200:
> Für Ocaml gibt's das nicht, aber es gibt "ledit", ein "line editor",
> den man wie folgt verwenden kann:
>     ledit ocaml
> Ocaml macht nach wie vor billiges stdin/stdout, und ledit kümmert
> sich um History und Co. Sogar eine sehr primitive rein text-
> baiserte Tab-Vervollständigung hat es (leider durch "ESC-/" statt
> "Tab" ausgelöst .. wtf?!).

Interessantes Werkzeug, das ledit!

Das man da nicht TAB nimmt macht evtl. Sinn, wenn man u.U. Input aus
Datein hat. Wäre ja komisch, wenn man ein File über ssh und ledit piped
und plötzlich die Einrückungstabs vervollständigen oder so... (geraten)

> ------------------------------------------------------------------
> 
> Wir haben hier also zwei grundverschiedene Ansätze: Auf der einen
> Seite die Aufgabentrennung im klassischen Unix-Stil:
> - "ledit" als universelle Kommandozeile
> - der Interpreter (z.B. Ocaml), der durch Pipelines angesteuert wird
> 
> Auf der anderen Seite eine enge Kopplung ala "ipython", die auch
> höhere Ansprüche bedienen kann. z.B. braucht man ne enge Verbindung
> für die Tab-Autovervollständigung. Die ist ja abhängig ist von dem,
> was man in der Interpretersitzung gerade definiert oder importiert hat.

Ja, und noch eine Million mehr Erweiterungen sind denkbar. Das kann man
meiner Meinung nach auf Editor vs. IDE übertragen: lieber ein
universeller Editor (vim) oder enge Kopplung die spezielle Features
bietet (Eclipse)?

> Nun wird aber "ipython" intern ebenfalls eine Aufgabentrennung haben,
> und für alle "Interpreter-Aufgaben" entsprechende Libraries verwenden.
> Das heißt, die Ansätze konkurrieren eigentlich auf einer ganz anderen
> Ebene: Trennt man die Aufgabe in zwei Prozesse mit einfacher/universeller
> Schnittstelle, oder trennt man sie durch dynamisches Linken gegen eine
> entsprechende Bibliothek, d.h. mit einer API als Schnittstelle?

Na, ganz so nicht, glaube ich. Zunächst macht die unix terminal line
discipline ja normalerweise mindestens schonmal Backspace möglich. Sowas
in der Art hat man dann ja immer auf der "ganz universellen
Schnittstelle".

> Wie seht ihr das? Sind das zwei gleichberechtigte Ansätze, oder
> gibt es sowas wie Design-Richtlinien, welchen man i.d.R. bevorzugen
> sollte?
> 
> Sie beide haben Vor- und Nachteile, aber es gibt so viele Fälle,
> in denen man erstmal nicht weiß, welcher Ansatz das bessere Design
> liefert.

Na ja klar. Meiner Meinung nach ist der erste Ansatz universeller und
mehr "Baukastenprinzip". Da leben Tools wie ledit oder auch vim, pipes
usw. Der zweite, monolitschere Ansatz (der natürlich über Bibliotheken
oder sonstwie implementiert wird, dies aber von aussen unsichtbar und
daher egal ist) kann natürlich in Spezialfällen stärker sein, aber ist
natürlich weniger allgemein. Sieht man IMHO auch sehr gut an Eclipse.
Kann man bestimmt prima Java-Bezeichner vervollständigen, aber um damit
ne E-Mail zu schreiben, braucht man sicherlich ein Plug-In. Bei vim geht
Vervollständigung dann nicht mehr semantisch und man hat keine
Syntaxcheckerei im Hintergrund (ich mag das eh nicht :)), dafür geht
Mail und SQL einfach mal so im Buffer nebenan. Mit Plug-Ins können dann
allgemein Editorenbetriebssysteme wie Emacs news lesen...

> Bin ich auf eine uralte ungelöste Grundsatzfrage gestoßen, oder gibt
> es dazu inzwischen Forschungen, die greifbare Antworten liefern, die
> über das "Designer-Bauchgefühl" hinaus gehen?

Ja, Standard, oder? Ist "Editor vs. IDE", oder "Baukasten vs. Monolit"
oder "Unix vs. Windows", finde ich. Warum sollte ein ipython notwendig
sein, wenn man doch ein Script schreiben kann? Gibt Fälle, klar, aber
vermutlich gibts das ipython auch, weil es einfach zu realisieren war.
In der Java-Welt z.B. gibts Millionen Zeilen grosse Applicationserver,
die auch bloss das nachbauen, was ein Linux schon hat (logging zB), aber
für Java hab ich noch keine Shell gesehen. Java behauptet zwar,
Baukästen zu nutzen, in Wirklichkeit hat man dann aber viele grosse
einmal-Baukästen (nimm dies oder jenes Framework - aber ne Mischung
daraus geht dann schlecht). MicroSoft schraubt an der PowerShell, mit
der man dann interaktiv DOM und ActiveAlles und so weiter nutzen kann.

Klingt erstmal nach einer "neuen Dimension an Möglichkeiten", aber ich
denke, man muss erstmal abwarten, ob das aufgeht. Bei Java hiess es
auch, man hätte C++ nicht schlecht kopiert, sondern verbessert
neuerfunden. War (und ist) ziemlich gehypt. Heute bin ich z.B. der
Meinung, das C++ halt mächtiger, sauberer und damit schöner ist, die
Java-Vereinfachungen zu unnötiger Komplexität auf höhreren Ebenen
führen, was IMHO wirklich schlecht ist (!!!) und major frameworks in der
dritten inkompatiblen Generation daher kommen. Dabei muss man
gerechterweise natürlich auch sagen, dass es etliche grosse,
funktionierende Javaapplikationen gibt und geben wird - und, soweit das
Ziel voll erreicht - keine Segfaults und Overflows (Sicherheitslücken
gabs auch, aber soweit ich weiss, vorbildlich wenig, weil gutes Sandbox
konzept - mit teurer VM erkauft, aber funktioniert).

Mal abwarten, wie das mit Sachen wie PowerShell entwickelt. Vielleicht
merkt man ja, dass es für genau die Beispiele funktioniert, aber die
Welt am Ende weder voll objektorientiert noch eine lange PIPE ist.

> Jedoch ist mittlerweile auch ein moderneres Ocaml-Toplevel in
> Arbeit, vielleicht kann es irgendwann mit ipython konkurrieren.

wozu braucht man das? Weil man keinen debugger hat? Bei perl gibts sowas
auch nicht, aber einen Debugger, da geht sowas (wohl), da kann man ddd
als Frontend nehmen. Macht man C, sind die Möglichkeiten des gdb arg
begrenzt (beliebige freie Funktionsaufrufe gehen aber, damit kriegt man
schon verdammt viel hin).

Vermutlich liegt die Grundsatzdiskussion sogar noch tiefer. Wann und wie
nehme ich Scriptsprachen bzw. wie streng sollte welche Sprache wann
sein? Die Java-Gemeinde war bis vor kurzem z.B. ziemlich auf eine
Sprache (halt Java) fokussiert. Na, XML vielleicht noch. Da wurden dann
Sourcecodegenerierer in Java gemacht und via XML und ant gestartet oder
so. Inzwischen kommt auch ein Scripttrend in Sachen wie groovy, wo man
mit Scriptsprachen an Designs und Implementierungen vorbei sonstwas
machen kann. Wozu auch immer man das braucht. Ich hab den Eindruck, dass
braucht man, um an schlechten Designs vorbeizuprogrammieren naja.

Sicherlich braucht man am Ende Flexiblität. Java ist gut für ne
Swing-Anwendung, für was wichtiges ("Kerne") nimmt man vielleicht ein
doch ausgereifteres Design und implementiert das in C++ oder gar Ada.
Sourcecodegenerierung (die man braucht, weil eine Sprache nicht alles
können SOLLEN, weil oversized) schreit IMHO nach Scriptsprachen wie z.B.
Perl. Für Spezialanwendungen hat man dann Spezialsprachen (wie Makefile
oder ant-Scripts).

(Mist, doch wieder so eine lange Labermail geworden grpmf)

oki,

Steffen

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





Mehr Informationen über die Mailingliste linux-l