[linux-l] Ocml vs. Java

So Okt 2 14:57:19 CEST 2005

On Sun, Oct 02, 2005 at 12:55:27AM +0200, Volker Grabsch wrote:
> On Mon, Sep 26, 2005 at 04:38:28AM +0200, Oliver Bandel wrote:
> > [...]

[...]
> Außerdem: Schon prinzipiell packe ich nichts in eine Liste, von dem
> ich 1. im Voraus die Größe nicht abschätzen kann und 2. nur
> sequentiellen Zugriff brauche. Das ist für mich eine Grundregel des
> gesunden Programmierer-Verstands.

Wenn klar ist, daß es bei der Funktionalität bleibt...

...so manches Tool wird aber früher oder später größer...
...und dann braucht man doch wieder die Sachen als Datenstruktur,
weil man ggf. mehrere Passes braucht.

[...]
> Dass ich nen Iterator brauche. Außerdem wollte ich nen "funktionaleren"
> Ansatz von dir.

Hmhhh... mal sgats Du, es macht keinen Sinn die Sachen in OCaml
nachzbilden, dann wieder willst Du es funktionaler.

Kannst ja mal schauen:

==============================================================
let ignore_leading_spaces str =
   let max_idx = String.length str - 1 in 
     let string_rest po = String.sub str po (max_idx - po +1) in
       let rec traverse pos = match str.[pos] with
          ' ' -> if pos < max_idx then traverse (pos+1) else string_rest pos
         | _  -> string_rest pos
   in
     traverse 0

let prepend_xxx  channel =
      let line = input_line channel
      in ("XXX" ^ ignore_leading_spaces line )

let _ =
    let read_from = open_in "./data.txt"
    in
    let closure () = prepend_xxx read_from in
      try 
        while true do
          print_endline (closure());
        done
      with End_of_file -> print_endline "fine. :)"
==============================================================

==============================================================
first:~/Programmierung/ocaml-versuche/schreibe-XXX-vor-die-Zeile oliver$ cat data.txt 
/usr/
/usr//bin
/usr//bin/a2p
/usr//bin/aclocal
  /usr//bin/aclocal-1.6
/usr//bin/addftinfo
/usr//bin/afmtodit
  /usr//bin/ant
/usr//bin/appleping
/usr//bin/appletviewer
/usr//bin/apply
  /usr//bin/apropos
/usr//bin/ar
/usr//bin/arch
first:~/Programmierung/ocaml-versuche/schreibe-XXX-vor-die-Zeile oliver$ ocaml reader.ml 
XXX/usr/
XXX/usr//bin
XXX/usr//bin/a2p
XXX/usr//bin/aclocal
XXX/usr//bin/aclocal-1.6
XXX/usr//bin/addftinfo
XXX/usr//bin/afmtodit
XXX/usr//bin/ant
XXX/usr//bin/appleping
XXX/usr//bin/appletviewer
XXX/usr//bin/apply
XXX/usr//bin/apropos
XXX/usr//bin/ar
XXX/usr//bin/arch
fine. :)
first:~/Programmierung/ocaml-versuche/schreibe-XXX-vor-die-Zeile oliver$ 
==============================================================

Meinst Du es so?!

[...] 
> Och, nun komm. Du packst das Problem an der falschen Ecke an. Diese
> Details sind mir völlig unwichtig. Von mir aus gehe davon aus, dass
> du nen Iterator gegeben hast, der dir die Eingabedatei zeilenweise
> liefert.
[...] 

Ich gehe davon aus, daß ich das ohne vorgegebene Sachen angehe (s.o.).

[...] 
> > > Wenn ich z.B. für's Wikidok-Projekt etwas
> > > schreibe, werden wohl viel weniger Klassen drin vorkommen.  :-)
> > 
> > Wikidok-Projekt klingt für mich irgdnwie nach FPLs... ;-)
> 
> Ich glaube, das ist das unwichtigste Detail.

Nö. Wenn FP für sowas gut geeignet ist, nimmt man eben FP.
Bei einer GUI würde man eher OO nehmen.

> Die Architektur des
> gesamten Systems ist das Innovative. Die konkreten Parser könnten
> theoretisch auch jeder in einer anderen Programmiersprache unter
> anderen Paradigmen geschrieben sein. :-)

Aber vermutlich viel aufwäniger.

Gerade was so Parserei, Datenstrukturen usw. angeht, sind doch FPLs gut geeignet.
Da kann man recht einfache Formulierungen für die Probleme finden.

[...]
> > Ich mache das ganz gerne, daß ich mir immer erst mal alles in den RAM
> > lese, Datenstrukturen aufbaue und dann damit arbeite.
> > Das hat nämlich den Vorteil, daß man die Datenstrukturen auch mehrfach nutzen
> > kann und nicht immer wieder die Datei neu einlesen.
> 
> Wenn ich nen Algorithmus habe, der den Datenbestand sequentiell
> durchlaufen kann und dabei effizient arbeitet und nur wenig Speicher
> verbraucht, dann implementiere ich *diesen* und keinen anderen.

Naja, wenn es bei dem speziellen Anwendungsfall bleibt, ist das auch ok.

> Das
> ist ja wohl der Mindestanspruch an mich selbst, dass ich mich bemühe,
> wenigstens den grundlegenden Algorithmus effizient zu gestalten.

Das widerspricht ja nicht dem, daß man Datenstrukturen aufbaut.
Ausser, wenn man *definitiv* weiß, daß man die Daten nur einmal
braucht.

> 
> > Und bei Programmänderunegn ist man auch flexibler.
> 
> Brauch ich später ne Liste, kippe ich den Iterator in eine Liste ab. :-)

Na jut. ;-)

> 
> > Und wenn man die Daten übers netz liest, dann kann man cuh nicht
> > noch mal neu einlesen, so wie bei einer Datei.
> > 
> > Grundsätzlich ist es IMHO das sinnvollste, immer erst Datenstrukturen
> > aufzubauen und dann damit zu arbeiten.
> > 
> > Natürlich gibt es Ausnahmen, aber das muß man sich dann gesondert anschauen.
> 
> Diese "Ausnahmen" sind aber sehr verbreitet. In meinen bisherigen
> Programmen sind die Daten entweder von der Sorte, dass sie in ne
> Datenbank gehören (von mir aus auch in ne Datenstruktur im RAM), oder
> von der Sorte, dass ich sie sequentiell in eine Datei oder einen Filter
> kippe.
> 
> Wenn meine Applikation z.B. einen Druckauftrag generiert, dann müssen
> mehrere Objekte in zusammenabrbeit eine Datenstruktur aufbauen. z.B.
> geht ein Rechnungsobjekt die Rechnungs-Positionen durch, jede generiert
> ihre Zeile in der Tabelle. Weiterhin lässt das Rechnungsobjekt die
> Adresse vom Kunden-Objekt generieren, und bastelt das alles schön
> zusammen. Natürlich noch Drucker-Unabhängig, einfach nur als allgemeine
> Datenstruktur, die am Ende z.B. in ein XML-File gekippt werden, aus der
> alles weitere generiert wird.
> 
> Ich baue also eine Struktur auf, die am Ende nur serialisiert werden
> braucht. Muss ich sie deshalb im RAM behalten?

Wenn Du sie mehrfach brauchst?
Z.B. Einen Brief, aber mit mehreren Empfängern...
...willst Du immer den selben Brief mehrfach aufbauen?
Statt dessen die selbe Datanstruktur nehmen und immer bloß an der
richtigen Stelle das Adressfeld ändern.

[...]
> > > Aber sobald du Polymorphie brauchst, hast du sowieso einen gewissen
> > > Overhead,
> > 
> > Nö, bei FPLs nicht.
> > Da ist die Polymorphie schon gleich mit als Bonus dabei.
> > Ist halt ne andere Art von Polymorphie; da geht es um Typen,
> > nicht um Methoden-Aufrufe.
> 
> Ich hab in Ocaml nachgelesen: Diese Art von Polymorphie (Funktionen-
> Polymorphie) meinte ich überhaupt nicht. Ich meinte die Polymorphie
> von Objekten.

Das ist es, wenn ich meine: Bestimmte Herangehensweisen (z.B. OO-Ansatz)
führt dazu, daß man bestimmte Probleme in einer gewissen Weise lösen
muß (mit OO-Konstrukten).
Vermutlich hätte ein grundlegend anderer Ansatz dazu geführt, daß
Du nicht nach Polymorphie von Objekten ausschau halten musst.

> 
> > > den du in diesem Fall aber gerne in Kauf nimmst, weil er
> > > mikrig ist im Vergleich zur Alternative. Ein kleines dummes Beispiel:
> > 
> > Naja, das beispiel ist immer so ein typisches.
> > Ob man in dem Falle OO anwenden sollte... hmhhh.
> > Kann man schon machen, bzw. wird oft gemacht.
> > Aber FP-Ansatz mag ggf. auch passen.
> > 
> > Könnte man sich echt mal nen Kopp zu machen... ;-)
> 
> Ja, aber erfinde das Rad dabei nicht neu. :-)

Ach nun doch nicht?
Ich dachte, es macht keinen Sinn, wenn ich die Sachen,
die Du in Python per OO gemacht hast nochmal reimplementiere.
Also doch noch ein neues Rad erfinden, statt reimplemntieren.

Nun also doch nicht neu erfinden?

Viell. reden wir wieder mal aneinander vorbei.

[...]
> > > Nicht unbedingt. Wenn man es missbraucht, dann schon. Aber wenn man es
> > > wirklich mit Klassen zu tun hat, sollte man sie in der Programmiersprache
> > > auch als Klassen programmieren können.
> > 
> > Was meinst Du damit?
> > Du meinst, wenn man die Sachlage, die man im Rechner abbildet auch
> > in der Real-World OO-like gut beschrieben wrden können?
> > Wenn also OO eine brauchbare Hrangehensweise darstellen?
> 
> Wie ein anderer Poster bereits bemerkte: Wenn ich tatsächlich mehrere
> Funktionen habe, die an gewisse Daten gebunden sind, dann sollte man
> sie nach OO-Manier zu einer Klasse zusammenfassen.

Ach, also nur weil String-Funktionen an String-Daten gebunden sind
und mit Integers nix zu tun haben, muß man die noch lange nicht
als klasse zusammen fassen. Module tun es auch.

Aber wir drehen uns im Kreise.

Allmählich denke ich, haben wir das Thema schon seeehr weit auf gedröselt
und diskutieren immer noch an den selbsne Stellen... das wird allmählich
öde. Naja, ok, ein bischen weiter sind wir schon.

Aber wenn solche Diskussionen sich zu MegaThredas ausweiten und den gesamten
Tag mit Zeitbedarf in sich hinein saugen, dann ätzt es doch... weil ich da
dann doch lieber mal wieder was konkret machen wollte.

Habe mir mal wieder ein projkt heraus gesucht, das ich schon seit langem mal
bearbeiten wollte; seit gestern habe ich da etwas Muße zu.

Gruß,
   Oliver