[linux-l] LinuxScript?

[Steffen Dettmer]

* Oliver Bandel wrote on Thu, Apr 04, 2002 at 22:21 +0200:
> On Thu, 4 Apr 2002, Steffen Dettmer wrote:
> > * Oliver Bandel wrote on Wed, Apr 03, 2002 at 12:56 +0200:
> > > On Wed, 3 Apr 2002, Steffen Dettmer wrote:

> > > Ich weiß, was man in Perl machen kann.
> > 
> > Gerade nach den noch im Zitat folgenden Aussagen kann ich mir das
> > nicht wirklich vorstellen. [1], [2]
> 
> Es ist eben eine Frage der persönlöichen Einschätzung,
> ob man findet, daß eine Sprache sehr viel mehr kann als
> eine andere, oder ob man denkt, der Unterschied ist gering.

Wenn man sich nicht in eine Sprache eingearbeitet hat und/oder
deren Konzepte nicht versteht, soll man eben nicht sagen, daß sie
Mist ist. Außerdem provozieren ja solche Aussagen geradezu
unfreundlichere Gegenaussagen.

> > > > 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.
> > 
> > Ja, und was denn nun?
> 
> Ich kann Dir nicht das in dieser einen Mail alles aufzählen,
> worüber viele Forscher weltweit seit Jahrzehnten forschen.

Beispiele, die nicht in Perl oder so "nachahmbar" sind, hätten
auch gereicht...

> Die Unterlagen aus Deinem Studium waren offensichtlich nicht dazu
> geeignet, Dir die Unterschiede aufzuzeigen.

Oder man hielt funktionale Programmierung nicht für wesentlich
genug, sie in den Lehrplan aufzunehmen.

> Funktionale Programmierung hat den Vorteil, daß die Funktionen *immer*
> das gleiche Ergebnis hervorbringen, egal, wann, wo, wie man sie
> aufruft. Man hat input-parameter und man hat ein Ergebnis.

Ich habe immer noch nicht verstanden, warum es gut ist, Zahlen
mit Listen zu vergleichen. Da meines Wissens nach hierfür kein
mathematischer Standardoperator definiert ist, halte ich das
erstmal für unschön, nach wie vor.

> Bei imperativen Sprachen hat man ggf. (und in der
> Praxis taucht das trotz aller Bemühungen immer wieder auf)
> mit den Seiteneffekten zu kämpfen hat.

Wie ich bereits sagte, mit genügend krimineller Energie kriegt
man sowas hin. Aber in "normalen" Programmen macht man sowas ja
eben nicht. Nur, weil etwas "geht", *muß* man es ja nicht machen.
Und wenn man sich mal irgentwann in den Fuß schießen *muß*,
*kann* man eben. 

> Im Allgemeinen bieten die FPLs mächtigen Sprachumfang mit einem
> excellenten Klassensystem, Modulsystem, etc.

Sagtest Du bereits, und ich sagte bereits, daß auch Java, Perl
usw. das haben,

> Noch ein schönes Schmankerl: OCaml z.B. erkennt automatisch den Typ
> eines Ausdrucks. :)

Macht Perl auch. Obwohl man sich hier wieder fragen muß, ob man
das möchte.

> Wenn Du wirklich daran interessiert bist und mich nicht nur
> trollender Weise provozieren willst, dann liest Du Dich
> selbst in die Materie ein.

Das kann ich akzeptieren, man hat ja nicht unendlich Zeit. Bloß
ein bißchen schade, daß ich mir so viel Mühe gegeben habe, alles
mit "Pseudocode" zu erklären, was ich meinte, und viel Arbeit
inverstiert habe, um meine Standpunkte zu erläutern, und Du jetzt
sagst: "lies selbst, ich weiß es auch nicht"...

> Ich habe den Eindruck, Du bist garnicht daran interessiert,
> etwas Neues zu finden und zu lernen, sondern daß es hier
> um die typischen "ich-bin-ein-Dauerthread"-Spielchen geht.

Was ist daran "typisch"? Egal. Die Unterstellung habe ich
geflissentlich ignoriert.

> Darauf habe ich keine Böcke.

Den Eindruck hab ich auch. Schön, daß Du wenigstens dazu stehst.

[Forscher usw., die z.B. Java mit designed haben...]
> Vor solchen Leuten jedenfalls habe ich Respekt und wenn ich sehe,
> wie elegant man Probleme mit FPLs lösen kann, dann weiß ich, daß
> diese Leute keine Spinner sind und ihre Erfahrungen etwas zählen.

Ich kann mir jedoch kaum vorstellen, daß diese Java als Kack
bezeichnen (oder wie Du Dich auch ausdrücktest). Vielleicht
solltest Du vorsichtiger mit solchen Aussagen sein?

> Ich wollte nur sagen, was mir an der einin oder anderen
> Sparache gefällt.

Ich wollte das gleiche sagen. Ich habe mir Mühe gegeben, es
ausführlich und detailiert mit Beispielen zu erkären. Dann hab
ich den ersten Link von Dir gelesen und er hat überhaupt nichts
wichtiges beigetragen. Nur mal zur Erinnerung.

> Nach Dauerthraead ohne Ergebnis steht mir der Sinn nicht.

Vielleicht solltest Du Dich auch mal fragen, warum hier kein
Ergebnis in Sicht ist?

> Solche Spielereien habe ich schon mit anderen Themen (Linux
> z.B.) sehr lange gemacht und irgendwann nervt dieses
> rumgestreite. Es geht oft nicht um die Sache.

Aha. Bei Deinen Diskussionen geht es also oft nicht um die Sache.
Na ja, bei mir ist das anders.

> Wenn's Dir um die Sache geht, lies demnächst auf comp.lang.functional
> mit.

Ich wollte lediglich mit *Dir* das diskutieren. Wenn Du das nicht
möchstest, hättest Du das auch etwas früher sagen können.

> > > > Weil es C++ gibt.
> > > 
> > > Lohnt sich der Lernaufwand nicht. :)
> > 
> > Immer diese unbegründeten Aussagen...
> 
> Ebenso wie Deine.

Was sollte ich daran bitte begründen? Deine Aussage ist nicht
begündet, weil keine weitere Erklärung oder andere Information
vor oder nach der Behauptung folgt. Ich halte sie für falsch,
weil mit C++ viel in der Praxis entwicklet wird und viele Leute
damit ihre Brötchen verdienen. 

> Wenn Du wissen willst, welches die Gründe sind, schau Dir
> die Sprachen an. Ich kann Hinweise geben. Alles in den
> Arsch schieben tue ich nicht.

Da ich erklärt habe, habe ich Dir demzufolge "alles in der Arsch
geschoben"? Interessant.

> Wenn Du meinst, es ist alles Kack, was ich hier erzähle, ist es
> Dein Problem.

*Du* warst derjenige, der solche Wörter in diesen Thread brachte.
Da Du sicherlich die vorherigen Mails hast, kannst Du da ggf.
nochmal nachlesen, was Du schriebst.

[Buch über Ocaml]
> Schau doch da rein. Ich kann Dir auch noch die URL schicken.
> Abe warum soll ich das jetzt hier alles wiederholen,
> wenn ich Dir schon gesagt habe, wo Du es finden kannst?
> Beurteile es doch selbst; mir scheinst Du ja immer etwas
> entgegenhalten zu müssen.

Ich denke eher, Du hattest meinen Argumenten nichts
entgegenzusetzen. Es ist ja normal, daß man zu Argumenten
Gegenargumente bringt. Das nennt man dann Diskussion.

> Also: Lies selbst und entscheide selbst. Wenn Du dann immernoch
> denkst, daß das alles kack ist, laß es mich wissen, ich lerne
> gern' dazu.

Bitte unterstelle mir nicht solche Aussagen, flüchtige Leser
könnten Die glauben und das würde mich ärgern.

> [...] 
> > > > Wenn ich ne Funktion auf einer Liste habe, kann ich da
> > > > doch keine Zahl angeben, oder? Macht doch keinen Sinn.
> > > 
> > > Macht Sinn.
> > 
> > OK, Aussage erkannt. Begründung nicht gefunden...
> 
> Habe den Kontext verloren.
> Was genau ist die Frage (ohne 10 k Quoting auf drei Ebenen)?

Der Kontext steht eingige Zeilen weiter oben. Ich fragte nach dem
Sinn einer Funktion, die auf einer Liste arbeitet, jedoch keine
Liste, sondern eine Zahl als Parameter erhält. Listen bzw.
Vektoren, wie man sich in der Mathematik bezeichnen würde, und
Zahlen sind grundlegend verschiede Sachen. Auch ein
eindimensionaler Vektor mit der Komponente 2 ist nicht zu
verwechseln mit der Zahl 2.

> > Wie sind die Standard-Operatoren zwischen Zahlen und
> > Listen/Mengen definiert?
> 
> Jede Sprache ist etwas unterschiedlich. Deshalb sind
> es ja auch mehrer und nicht eine Sprache.
> 
> 
> > Was ist denn nun [1,3] < [2] ?
> 
> In Haskell (hugs) direkt eingetippert ergibt das
> True

Und genau das macht meiner Meinung nach keinen Sinn. Man muß ja
den Operator definieren. Das kann man auf mehrere Arten machen:
man kann sagen, die jeweils kleinsten Elemente werden
arithmetisch verglichen, oder das jeweils größte, oder die Anzahl
der Elemente, oder ...

> In Ocaml wird der Typ der Expression automatisch erkannt
> (type inference). Und es gibt z.B. für int- und float-zahlen
> unterschiedliche Operatoren:
> + - * / bei int sind +. -. *. /. bei float gegenüber zu stellen.
> Da kann man nicht eben mal versehentlich int zu float konvertieren.
> 
> (Ist zwar in C ganz nett, aber das ist ja auch eine andere Philosophie:
> Da soll's gehen, hier soll's eben streng geprüft werden.)

In C sind int und float verschiedene Typen, die nicht impliziet
konvertiert werden. Die Operatoren verwenden analog zur
Mathematik die gleichen Symbole.

Das ist ein Unterschied, ja, aber sicherlich nicht der
Einsatzgrund Nr. 1 für funktionales Programmieren! Außerdem
sprachst Du Dich gegen Typconvertierungen aus:

[...casten...] 
> > > Das ist doch Vergewaltigung von Typensystemen.
> > 
> > Nicht unbedingt. Warum sollte ich nicht ein long int, der
> > nachweilslich kleiner als 1000 ist, nicht in einen short wandeln
> > können? Warum sollte ich ein int = 10 nicht als Zeichen und
> > Zeilenvorschub (oder so) interpretieren dürfen?
> 
> Widerspricht das nicht dem, nach dem man an Sicherheitsmechanismen
> sonst immer ruft? Strenge Typprüfung? Was nützt die, wenn man
> das wegcasten kann?

Wie Du schreibst: "kann" - nicht "muß". Es gibt eben Fälle, da
muß man können. Zum Beispiel, wenn man Zeichentabellen
umkodieren muß. Oder wenn man einen compressor oder eine
Hashfunktion verwendet. Da gibt es noch viele viele weitere
Beispiele.

> > Es macht schon
> > Sinn. Gerade, wenn man näher am System arbeitet.
> 
> Naja, warum dann erst ein long nehmen, wenn man dann doch herunter
> castet?

Weil man vielleicht nur castet, wenn z.B. der long kleiner als 10
ist, wie ich bereits schrieb IIRC. Man kann ja nicht immer
wissen, was passiert. Vielleicht hat man ja einen algorithmus,
der für shorts viel viel schneller ist, möchte aber auch longs
verarbeiten können, wenn denn mal eine große Zahl kommt. Sowas
kommt ja vor. 

> Ist doch unsauber.  Wenn man ein short braucht, nimmt man ein
> short.

Derartige Aussagen suggerieren mir, daß Du scheinbar wenig
Programiererfahrung mit C/C++ hast. Es gibt eben genug Fälle, wo
das nicht geht. In einem 20.000 Zeilenprogramm sind statisch
vermutlich meistens meherere solcher Fälle drin.

> (Ja, nimmt man in der Praxis oftmals nicht,

Doch, man nimmt passende Typen, so lange es eben geht.

>  aber das ist ja auch eines der größten Probleme in der
>  Programmierpraxis: man macht oftmals, was man lieber nicht
>  machen sollte.

Wenn man es oft macht, ist man vermutlich kein guter Entwickler.
Natürlich passiert sowas, schließlich macht jeder Fehler.

>  Auch in Perl kann man mit und ohne "use strict" herum werkeln...
>  man kann auch ohne, sollte man aber nicht => machen trotzdem
>  viel zu viele Leute...)

Es gibt sicherlich auch Fälle, wo use nostrict angebracht ist.
Das sollte man nicht grundsätzlich ablehnen. In der Regel ist es
jedoch so, und in der Regel haben gute Perlprogramme auch ein use
strict am Anfang.

[Funktionspointer casten]
> > Es ist schon ein Riesenunterschied, ob man es hinschreiben muß,
> > oder nicht! Ada kennt dafür die unchecked_conversion (IIRC). Wenn
> > es nicht anders *geht*, kann man das eben so machen.
> 
> Es macht aber einen noch größeren Unterschied (um mal auf obigen
> Punkt zurück zu kommen), wenn man seine funktionen so designt,
> daß man sie ohne Casterei zusammen baut.

Das macht man ja auch. Ich kann mich z.B. nicht erinnern, jemals
Funktionspointer gecastet zu haben.

> Letztlich kann ein cast auch nichts reparieren, was kaputt
> ist, soll heißen, passt die long-Zahl nicht in den Short, nützt
> der Cast auch nichts mehr. So what?

Wie Du richtig erkannt hast, kann es sein, daß eine long Zahl
nicht in einen short paßt. Demzufolge kann es aber auch sein, daß
sie rein paßt. Das kann man leicht zur Laufzeit abfangen, und das
wird auch gemacht.

> -> Auf casts verzichten und Funktionen nutzen, die entsprechende
>    Typen haben.

Das geht eben nicht. Schönes Beispiel ist Ada. Bei Ada gibt es
nicht nur eine Handvoll Integer-Typen, sondern jeder Integer-Typ
muß ein Gültigkeitsintervall haben, daß heißt, der Wertebereich
muß immer explizit angeben werden. In Ada sind also ints von 0
bis 100 und ints von 100 bis 200 verschiedene Typen.

Wenn Du nun eine Funktion schreiben sollst, die zwei ints
vertauschen soll, kann man das mit dem "cast" analogon sauber
lösen: man prüft, ob die Wertebereiche zum jeweils anderen
Argument passen (wenn nicht, wirft man eine Exception). Dann kann
man problemlos die Zahlen tauschen, auch wenn die jetzt andere
Typen haben.

Dies nur mal als ein weiteres Beispiel, um Dir zu zeigen, daß es
eben nicht grundsätzlich vermeidbar ist.

["int" cast in "char"]
> > Wäre ja umständlich, über 255 oder 65535 (unicode 16 bit) ein
> > switch-style Konstrukt zu bauen:
> > 
> > switch (int) {
> >  case   1:   c = '\1';
> > 	     break;
> >  case   2:   c = '\2':
> > 	     break;
> >  ...
> >  case 255:   c = '\255';
> > 	     break;
> >  default:    some_error();
> > }
> > 
> > Albern.
> 
> Statt dessen casten?

Ja.

> int? Welche Größe hat der int?

Jedenfalls bis 255. Sogar mindestens bis 65536.

>  (btw: der darf aber so nicht heissen)

Warum nicht?

>    => Implmattaionsabhängig in C.  Es gibt nur Mindest-Größe laut
>       C-Standard.

Ja, und diese liegt über 255. 

> Wozu überhaupt solch ein switch/case-construkt?

Um ein int in ein char zu kriegen, ohne zu casten. Ich wollte Dir
nur wiedermal ein Beispiel nennen, daß man sowas eben manchmal
braucht.

> Was ist mit mod? Oder ausmaskieren?

Wie jetzt?

> Du willst Dein Argument stützen, indem Du ein Gegenbeispiel
> widerlegst?

Ja, genau.

> Ich kann dem Switch-case da auch erst mal nichts sinnvolles
> abgewinnen.

Eben, also muß man casten. Das wollte ich auch nur zeigen.

> > Ich kenne den Ausdruck nur die Anwendung eines endlichen
> > Automaten (Typ 3 Grammatik oder reguläre Grammatik).
> 
> Aha, was ist eine Typ 3 Grammatik?
> Gute Links da?

Na ja, google fand z.B.:
http://www.iti.cs.tu-bs.de/~backer/typ3/typ3gra.html
http://wortschatz.informatik.uni-leipzig.de/asv/lehre/ws0102/HComLingKap04.pdf
http://www.inf.tu-dresden.de/ST1/ps/skripte/elemente.pdf
http://www.tutorialpage.de/Dvs/index.php?ziel=http://www.tutorialpage.de/Dvs/chap4.php

Ich empfehle mal den letzen, ist am einfachsten zu verstehen,
denke ich, weil nicht so formal (allerdings kann man genauso wie
rechtlineare auch linkslineare Typ 3 Grammatiken haben,
Hauptsache eben, linear, klar).

> > > Das Haskell-Beispiel war mit Pattern-Matching auf
> > > die Eingangsdaten (Argumente der Fkt.).
> > 
> > Ja, nun gut, wie gesagt, kann man sich ja auch in z.B. Perl
> > bauen.
> 
> Sieht vielleicht ähnlich aus.

Ja, und funktioniert ähnlich, also ist ähnlich, oder?!

> Aber FPLs arbeiten anders.

Wie: anders?! Mit keinem "mit Pattern-Matching auf die
Eingangsdaten (Argumente der Fkt.)"? Das war doch DEINE Aussage?!

> Das Pattern-Matching ist Typensicher;

Scheinbar nicht, wenn int und floats "automatisch erkannt"
werden, Listen und Zahlen wild gemischt werden können usw. 

> in Perl mußt Du Deine Argumente selbst auf Konsistenz prüfen.

Natürlich kann ein Compiler keine wirkliche Konsistenzprüfung
machen, weil diese ja erst zur Laufzeit möglich ist klar, das
gilt natürlich für alle Sprachen.

> Ausserdem bekommt man in OCaml/FPLs unvollständige Matches gemeldet,
> so daß es einem nicht entgeht, falls man einen möglichen
> Fall nicht abgehandelt hat.
> Das nenne ich sichere Programmierung.

Ist bei Ada auch ein Fehler, bei Java weiß ich jetzt nicht,
könnte ich mir aber auch vorstellen, daß es mind. ne Warnung
gibt.

> > > > >   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.
> > 
> > Ja, und?! Außerdem ist das static eher eine Linker-Anweisung,
> > aber egal. Was fehlt denn nun an C++'s Klassensystem?
> 
> Tja, vermisst Du nichts?

Doch, aber an ganz anderen Punkten.

> Da ich kein C++-er bin, reichen mir die Klagen anderer Leute
> und die Aussicht auf das, was OCaml mir bereit stellt.

Du solltest schon Argumente kennen... Ach, egal, keine Lust mehr.

> Parametrisierbare Klassen klingt jedenfalls interessant.

In C++ sind Klassen natürlich parametrisierbar (in verschiednen
Arten).

> Du kannst das sicherlich besser einschätzen, als ich,
> da Du ja wohl Informatik studiert hast?

Ach, soviel lernt man im Studium nicht über Praxis. Das ist ja
hinlänglich bekannt.

> Ich werde mir das Wissen noch aneignen, also kann ich Dir
> noch nichts zu parametrisierbaren Klassen erzählen.

Schön, daß Du es dann überhaupt anbringst...

[...]
> parametrized classes
> 
> Sollte Dich neugierig machen.

Du schmeißt hier nur mit Schlagwörtern rum, die mir nix sagen,
und mich demzufolge sicherlich nicht neugierig machen.

> Bin ja selbst relativer noch FPL-neuling, 

Warum sagst Du das nicht am Anfang der Diskussion?! Ich wunder
mich hier, warum Du nix erklären kannst, und jetzt stellt sich
herraus, daß Du in diesem Thema Neuling bist? Hättest Du das
nicht lieber schon in der zweiten Mail sagen sollen? Oder hab ich
das nur verpennt? Komisch.

> also kann ich Dir
> auch nicht alles runterbeten, was man in Deinem Studium
> vergaß Dir mitzuteilen. ;-)

Bitte lasse sowas lieber weg.

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

Merkst Du, das solche Aussagen nicht nur falsch sondern
kontraproduktiv sind? Nur mal BTW.

> > Was? Abstrakte Datentypen in C++? Geht doch prima!
> 
> Wie?

Wie unten steht.

> Libs?

Bitte?

> Und Algebraische Datentypen?

Kenn ich nicht. Was ist das?

> > > Wie soll man sowas in C++/Perl machen?
> > 
> > Was "sowas"? Abstrakte Datentypen in C++? Ganz einfach, man muß
> > nur ne pure virutelle Methode definieren, und die Klasse ist
> > abstrakt.
> 
> Aha. Klingt aufwendig.

Ist es aber nicht. Man schreibt lediglich "= 0" dahinter. Fand
der Erfinder wohl kürzer als ein Schlüsselwort "abstract" (Java),
aber ist ja auch egal, jedenfalls kein Aufwand.

> > > Wie machst Du das, wenn Du eine BNF hast in C++ oder Perl
> > > oder Java?
> > 
> > Einen regulären Ausdruck anwenden?
> 
> In Perl?

In Perl per Sprachsyntax.

> C++?

In C++ über eine Klasse oder Funktion.

> Library?

Ja, sicher aus einer library. Auch Perls und OCamls Funktionen
kommen daher, nur die Aufruf konverntionen sind anders (einmal
implizit, einmal explizit). Spielt aber keine elementare Rolle.

> > > > 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?
> > 
> > Gibt eine Lib dafür. Wie groß die Implementation ist, ist doch
> > egal. Der Ocaml Compiler braucht da auch ein paar Zeilen. Egal.
> > Es geht eben.
> 
> Also würdest Du C Perl vorziehen?

Bleibe bitte beim Thema.

> Das würe ich nur, wenn es wirklich aus zwingenden Gründen
> sein muß. Für einfache (Perl-like) Pattern-matches würe
> ich Perl C vorziehen. Warum? Weil man schneller zum Ergebnis
> kommt.

Man kann in einem Projekt nicht für jede Funktion eine andere
Sprache verwenden. Überhaupt kann man Sprachen nur schwierig
wechseln. Ich verwende halb Java, halb C++, ist schon schlimm
genug. Perl ist nett für kleine Scriptchen, so bis 1000 Zeilen
vielleicht, mehr braucht man meist nicht "zwischendurch". Perl
also für die Helferchens und so. Externe Sachen (CGI Interfaces)
kann man ganz gut in Perl machen (hab ich auch), aber innerhalb
einer Anwendung (GUI oder Server) geht das nicht wirklich schön.
Kann man natürlich machen, meistens überwiegen aber die
Nachteile.

> > Perl benutzt auch nur ne Lib. Nur die Syntax des Aufrufes ist
> > komfortabler. Aber das ist kein grundlegender Unterschied,
> > sondern eben Komfort.
> 
> Nun, wenn man aber FPLs nutzt., hat man die anderen
> Vorteile der selbigen,

"die anderen Vorteile der selbigen"? Soll mir das was sagen?!

> eben die VORAUSSAGBARKEIT DER ERGEBNISSE.

Hum?!

> FP ist sauberer, übersichtlicher als C/C++/Java-Gefrickel mit
> Seiteneffekten, errno-Nerv, kruden Verebungshierarchien, ...

Na ja, dann frickel mal ruhig weiter, aber bitte erzähle es nicht
öffentlich, denn sonst könnte jemand denken, auch viele andere
würden in C/C++/Java "rumfrickeln", mit Seiteneffekten arbeiten
"errno" unsauber verwenden und schlechte Verebungshierarchien
verwenden (das Wort "krude" sagt mir nix). 


> [...]
> > > Perl kommt ausserdem nicht gleichzeitig mit Interpreter,
> > > Bytecode-Compiler und Nativecode-Compiler daher.
> > 
> > Das interessiert doch überhaupt nicht. Perl macht eben
> > ausschließlich JIT, na und? 
> 
> Finde ich nicht na und.

Ist interessant, daß Du das "nicht findest", aber Perl macht das
nun mal so. Da gibt's nichts zu finden.

> > > Python kenne ich nicht im Detail. Sieht aber recht
> > > durchdacht aus, die Sache.
> > 
> > Welche Vorteile gegenüber Perl hat es denn nun konkret?
> 
> Schau Dir Beipielcode an, Du wirst sehen, er ist
> sauberer (OO-Notation springt gleich ins Auge),
> zumindest die Zeile, die ich so gesehen habe.

Sag mal, möchtest Du mich ärgern?! Wir diskutieren doch hier
nicht, weil Du eine verdammte Zeile Code gesehen hast, Dir und
Deinen "kruden Vererbunghierachien" sauberer scheint, und Dir aus
irgentwelchen hier nicht genannten Gründen ins Auge sprang (was
zudem ziemlich unerheblich ist)?

> > > > 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.
> > 
> > Ich sagte ja: "damit gibt es also keine Datenkapselung". 
> 
> Dann meinen wir das selbe, aber anscheinend reden wir aneinander
> vorbei.

Ich wiederhol aus erstem obrigem Zitat:
"damit gibt es also keine Datenkapselung" und aus zweitem:
"damit gibt es also keine Datenkapselung".

Beim zweiten stelltest Du fest, das wir das gleiche meinen. Ich
kann kein Unterschied zwischen dem ersten und dem zweiten Zitat
erkennen. Vielleicht liest Du nicht aufmerksam genug?

> Deswegen bin ich auch nicht besonders darauf erpicht, ewig
> lange Sprachfeatures auszudiskutieren.

Dann lasse es. Aber wenn Du Behauptungen aufstellst und Fragen
stellst, bist Du eben in dieser Diskussion.

 [...const in C...] 
>  geschluckt, da ist aber in K&RII nichts zu finden, was dem
>  eine sinnvolle Interpretation gibt).
> 
> => Auf Sand gebaut.

Erstens ist K&R nicht das Maß aller Dinge, und zweitens ist es
nicht auf Sand gebaut.

> > > Mannjahre java spart man, nimmt man OCAML. :)
> > 
> > Gibt's da überhaupt einen ORB für? Was ist mit einem GUI
> > Framework? Du weißt, wovon wir reden?!
> 
> Im Zweifelsfalle kann man die C-Schnittstelle von OCaml nutzen.

Wo spare ich dann noch?

> GUI: via Tk.

Gibt einen Tk Port dafür? Nicht schlecht.

> ORB (a la Corba?) => Libs.

Es gibt also OCaml LIbraries für Corba funktionen, ein language
Mapping etc? Nicht schlecht. Überrascht mich ehrlich.

> Echo-Server in OCaml:
> 
> #########
>   open Unix
>   let server ic oc = Printf.fprintf oc "%s\n" (input_line ic); flush oc

sieht irgentwie nach C aus, finde ich.

>   let _ = establish_server server (ADDR_INET (inet_addr_any, 9876))

sieht auch sehr nach C aus. 

> #########

Na ja, egal, weiß eh nicht, was Du damit sagen willst.

> > Ganz einfach: Eigentlich möchte man nur die geraden betrachten.
> > Hier muß man dazu also eine neue Liste anlegen, alle gerade
> > Elemente kopieren
> 
> Da reichen im Prinzip die Referenzen. Nur, daß der Programmierer
> sich darum nicht kümmern muß.
> 
> Oder meinst Du, der Algorithum als solcher könnte besser sein?

Die Realisierung des Algorithus ist schneller, um so weniger
überflüssigen Kram man macht, ist doch logisch.

> #########
>   primes = sieve [2..]
>   sieve (h:t) = h : sieve [ x | x <- t, x `mod` h /= 0 ]
> #########
> 
> Das hat Vorteile: Man kann hier den Algorithmus erkennen.

Na schön, das sieht mathematisch "gewohnter" aus, ja. 

> Eine entsprechende Eimplementierung in einer IPL wäre
> sicherlich schwerer zu entziffern.

Übungsfrage/Gewohnheitsfrage.

> Man wird die Ergebnisse sehr schnell vorliegen haben.

Sicher? Glaube ich nicht, ist doch extrem rechenaufwendig.


[... long cut...]
> Vorteile bei den News: Man hat die Verkettung aufgedröselt.
> Da kann man ggf.s mehrer Postings thematisch trennen. Hier läuft
> dann ja doch alles in den mailreader, der alles nebeneinander haut. :(

Mein MUA macht das so, wie Du es von News gewohnt bist, just BTW.

> Und's ist einfach zu lang (braucht auch viel Zeit zum Antworten;
> vielleicht wäre das bei'm Bier besser zu beguatschen ;)).

Ja, kostet definitiv zu viel Zeit.

> Habe das noch nicht ausprobiert. Was spricht dagegen, die
> GUI mit dafür gut ausgelegter Software zu bauen, aber
> die abstrakten Dinge mit einer FPL?

Na ja, weil man eben schlecht wechseln kann. Ich meine, man kann
ja nicht (effizient, sauber etc.) für's sortieren einen OCaml
programm in ein Javaprogramm einbauen.

> Ericcson nutzt Erlang (haben die selbst entwickelt). Low-Level
> machen die teils in C. Alles, was abstrakter ist und was
> mit Threading und Netz zu tun hat, machen die in Erlang.

Vermutlich haben die dann da ne spezielle, integrierte
C-Schnittstelle?

> > Na, dann: schon mal gute Besserung!!
> 
> Danke.
> 
> Die haben mir gleich alle 4 Weisheitszähne gezogen.

Na huch, und auf welcher Seite kaust Du nu?!

> Naja, muß ich nur einmal durch. Weitere Zähne von
> der Sorte habe ich nicht. ;)

:) Ich hab seitenweise machen lassen. Konnte man wenigstens auf
einer Seite kauen.

> P.S.: Hat das noch Sinn, sich durch so langes Textzeugs 
>       durch zu kauen (Autsch!;)).

Siehste, ist nicht gesund :)

oki,

Steffen

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