[linux-l] [OT (?)] FPLs und Anderes Gesülze (Re: [linux-l] LinuxScript?)
Oliver Bandel
oliver at first.in-berlin.de
Fr Apr 5 16:27:52 CEST 2002
Hi, letzter Versuch einer brauchbaren Diskussion ;-)
On Fri, 5 Apr 2002, Steffen Dettmer wrote:
> * 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:
[...]
> 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"...
Sorry, für Deinen Aufwand.
Ich fand den vielen Code zu viel Code.
Es hätte auch gereicht, zu sagen, daß nicht OO ist, was
ihm ähnelt. Habe bzgl. Unix-System ja nicht gesagt, daß
es OO ist (sonst hätte ich ja nicht nach einem "echten"
OO-Zugang a la AppleScript gefagt, wenn es ihn schon gäbe),
sondern daß es ähnelt.
Also, wenn ich nach umfangreichen Beispielen suche, sage ich
das explizit. Aber danke für die Mühe.
[gegenseitige Anpissrei gelöscht]
[...]
> Ich wollte lediglich mit *Dir* das diskutieren. Wenn Du das nicht
> möchstest, hättest Du das auch etwas früher sagen können.
[...]
Im Prinzip ja, aber nicht bei x * 10 k Text + n Quotingebenen
und soundsoviel Lines of Code... ( plus Zahnbonus ;-) ).
[weitere gegenseitige Anpisserei gelöscht]
> > [...]
> > > > > 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.
Falls es um den List Comprehension-Kram ging, müßte ich nochmal
bzgl. der Vergleichsoperatoren nachschauen.
Haskell ist aber gut durchdacht designt und daher habe ich
keine bedenken, daß es Murks sein könnte. Wenn Du willst, stelle die
Frage nochmal bezogen auf das, was Du wissen willst neu.
Ich kann mir nicht rauspicken, was Du wissen willst.
Also bitte ggf. Frage neu formulieren.
> 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.
Ja, sollte man nicht verwechseln.
>
> > > 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 ...
Tja, da siehste mal, wie doof das mit überladenen Operatoren
ist. ;-) Haskell überlädt nämlich Operatoren und ich darf mal
vermuten, daß hier die ersten Elemente verglichen werden.
Habe aber schon ne ganze Weile nicht mehr ge-Haskell-t,
deswegen müsste ich das nachblättern.
(Mache ich aber nicht, sonfern das nicht extra angetriggert
wird, aus Gründen der Zeitersparnis, was Du hoffentlich
verstehst).
>
> > 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.
Auch nicht, wenn sie "rein passen", wie in C?
In C wird dann nämlich implizit konvertiert.
[...]
> Das ist ein Unterschied, ja, aber sicherlich nicht der
> Einsatzgrund Nr. 1 für funktionales Programmieren! Außerdem
> sprachst Du Dich gegen Typconvertierungen aus:
Ja, richtig.
Dem habe ich hier nicht widersprochen.
C macht das aber so: int passt in float, also wird es
implizit gewandelt. Ebenso passt das short in int,
float passt in double usw.
[...]
> [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.
Du nutzt die ja eh nicht so oft. ;-)
(ok, ich hör schon auf. ;-))
[...]
> ["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.
Ich würde das mit if's abfragen und entsprechend
zuweisen; dann habe ich die Umwandlungsbedingung *explizit*
im Code stehen.
>
> > int? Welche Größe hat der int?
>
> Jedenfalls bis 255. Sogar mindestens bis 65536.
>
> > (btw: der darf aber so nicht heissen)
>
> Warum nicht?
Weil's ein Schlüsselwort der Sprache ist.
[...]
> > Was ist mit mod? Oder ausmaskieren?
>
> Wie jetzt?
Bitmaske z.B.. => alle oberen Bits wegschnippeln.
Auch dann hat man die Konvertierung expliziert (= lesbar
im Code, was man macht).
>
> > Du willst Dein Argument stützen, indem Du ein Gegenbeispiel
> > widerlegst?
>
> Ja, genau.
Tja, normalerweise kann man Theorien nicht beweisen,
sondern sie nur widerlegen.... mit Widerlegung des
Gegenarguments ist die Theorie aber nicht bewiesen,
sondern nur das Gegenargument abgeschmettert.
=> Kommt halt das nächste...
...aber lassen wir das. ;-)
[...]
> > > 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.:
[...]
Danke.
[...]
> > > > 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?!
Nicht schon wieder sowas. ;-)
>
> > Aber FPLs arbeiten anders.
>
> Wie: anders?! Mit keinem "mit Pattern-Matching auf die
> Eingangsdaten (Argumente der Fkt.)"? Das war doch DEINE Aussage?!
OK, war vielleicht etwas dünn.
Wenn Du Beispiele willst, sag es.
Das Problem dabei: Ohne selbst mit einer FPL gearbeitet zu haben,
oder Dir das etwas näher anzuschauen, wirst Du das nicht so ohne
weiteres verstehen. Musste schon mal selbst Ocaml installieren
und rum probieren, erst dann wird es klar.
Den Lambda-Kalkulus kann ich Dir nicht runterbeten, das lernt man
ja offensichtlich nicht mal im Informatikstudium. Falls ich
die Musse habe (oder eine Notwendigkeit dafür sehe), mir das mal
reinzuziehen, kann ich's vielleicht mal erklären.
Im Prinzip ist es simpel, aber...
>
> > Das Pattern-Matching ist Typensicher;
>
> Scheinbar nicht, wenn int und floats "automatisch erkannt"
> werden, Listen und Zahlen wild gemischt werden können usw.
Nicht nur int's und float's werden automatisch erkannt,
sondern alle Typen. Und man kann eben Listen und Zahlen
nicht "wild mischen", falls Du meinst, daß man in Listen
alles ablegen kann. Das kann man in PERL: Ist eh alles
Stringtext, und letztlich sind auch Listen aus Scalaren
aufgebaut und Hashes sind halt verkettete Scalare, Referenzen
sind auch Scalare. Klar, man kann auch ref() benutzen usw.,
aber man kann zur Laufzeit auch alles wieder umbauen.
Der Vorteil der Flexibilität fällt einem da auf die Füsse!
Bei OCaml/Haskell hast Du in Listen immer nur Elemente eines Typs.
Ansonsten gibt's nen Type-Error.
Und in diesem Sinne kann da nichts "wild gemischt werden".
(In Scheme hingegen kann man Listen mit Elementen verschiednen
Typs nutzen.)
Man kann natürlich einer Funktion auch Argumente
verschiedenen Typs übergeben: z.B. ein int, ein float,
eine Liste mit Funktionen, die int als Parameter haben und
Funktionen mit anderem Typ zurückgeben... usw.
Aber es muß immer jedes Argument genau einen Typ haben, sonst
meckert der Compiler (und zur Laufzeit läßt sich das nicht
ändern).
Bei Perl kann ich in ein Hash oder Array ablegen, was mir beliebt,
also z.B. Scalare (Zahlen (int/float), Strings), Array-refs, hash-Refs,
sub-Refs, ... und ich kann auch das OO-System "überlisten" oder
in anderen Modulen in den Namespace eindringen, was man aber
natürlich "nicht macht" (Perl-Philosophie: nicht alles, was man
machen kann, sollte man auch machen - aber man sollte es machen
können können).
>
> > 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.
Nein. Eben nicht.
Typenkonsistenz kann man eben erzwingen.
Du kannst zur Laufzeit keine floats an Funktionen übergeben,
die int's erwarten, weil der Code nämlich sonst garnicht erst
compiliert wird.
In C kann man wild rum pointern oder casten und hat dann
"schnell eben" was nettes zusammen gebaut. Hat man was übersehen
(Laufzeitbedingung), dann fliegt man damit auf die Fresse,
weil's einem dann die Daten um die Ohren haut und man mit
nem SIGSEGV und entsprechend eingestellter Corefilegröße
mal eben n x 10 MB Corefile auf die Platte geballert bekommt.
(Wenn man damit gerne lebt, ist es völlig ok, in C zu programmieren ;-))
[...]
> > Tja, vermisst Du nichts?
>
> Doch, aber an ganz anderen Punkten.
An welchen Punkten denn?
[...]
> > Parametrisierbare Klassen klingt jedenfalls interessant.
>
> In C++ sind Klassen natürlich parametrisierbar (in verschiednen
> Arten).
Aha.
Naja, bin halt kein C++-ler.
Der Ansatz "sag mir was die Sprache xxx kann" klappt in diesem
Falle nicht, um die Unterschiede aufzuzeigen.
Vielleicht kommen wir weiter mit "ich sag dir, was mir bei yyy fehlt",
denn dann kann ich mal schauen, ob man's bei den FPLs findet.
So ist eigentlich auch mein Grundsätzliches Vorghehen: Ich will
ein Problem lösen, dann schaue ich danach, wie das geht und wenn
das die eine Sprache nicht kann, schaue ich, welche Sprache
hilft mir zur Problemlösung.
Der andere Weg: Meine Sprache kann x,y,z,... und deswegen
programmiere ich auch nur mit ihr, klappt so nicht.
OCaml bietet mir verschiedene Möglichkeiten zur Programmierung,
welche ich als sinnvoll ansehe, deswegen will ich die Sprache
nutzen, denn dies scheint ein gangbarer Weg zur Lösung komplexer
Probleme zu sein. Ich kann Dir noch nicht alle Sprachfeatures
im Detail erklären, da ich mir erst mal die schnuckeligsten
(higher-order-functions) angeschaut hatte. Die waren ausschlaggebend,
mich mit FPLs (Haskell, OCaml) zu befassen.
OO ist nett, aber im Moment ist das nicht mein Focus. Wenn ich's
brauche, weiß ich, daß ich bei Ocaml damit gut versorgt bin.
(BTW: Es gibt genügend FPLer, die meinen, nett die OO-Features zu
haben, aber OO braucht man eh kaum, wenn man mit FPLs arbeitet...)
Kurz gesagt: Deswegen kann ich Dir nicht aufzählen, was Du
bei OCaml findest, das Du vielleicht bei C++ vermisst,
und eben weil ich nicht weiß, was Du da vermisst.
(Da kann ich auf's Handbuch bzw. das O'Reilly-Buch verweisen;
wenn Du da Features findest, die Du suchst, prima; wenn nicht,
ist's vermutlich auch nicht eine Sprache für Dich.)
[...]
> > 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.
Siehste, und ich kenne mich mit Programmierpraxis aus, finde
aber nicht immer "des Informatikers richtige Worte".
Einschätzen der Qualität einer Sprache kann ich aber sehr wohl,
auch wenn ich nicht fachgerecht formulierte Sprache benutze,
oder nicht jedes (mir nochgarnicht wichtiges) OO-Sprachfeature
kenne (das mich derzeit auch nur marginal interessiert, aber
wichtig genug ist, um zu wissen: gut, daß es es gibt, sprich
implementiert ist - falls ich#s ja doch mal brauch').
>
> > 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...
Ich dachte, es hilft Dir weiter.
Mich interessieren die funktionalen Features halt mehr als die
OO-Sachen.
[...]
> > 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.
Daß ich nichts erklären kann?
Man kann das nicht vermitteln, wenn der Rezipient es nicht praktisch
ausprobiert. Ich habe FPL-Features benutzt und die Vorzüge
in meiner nicht-Informatiker-Sprache dargebracht.
Da gibt es nun bei der Verständigung mehrere Probleme:
1) Ich benutze möglicherweise nicht immer Informatiker-Jargon
2) Dir fehlt dir Praxis.
3) Ich kenne die dahinter liegende Theorie (Lambda-Kalkulus)
nur überblicksweise und überlasse die selbige solange den
Theoretikern, bis ich meine, sie mir auch aneignen zu müssen.
zu 2): Offensichtlich gab es in Deinen Unterlagen ja Informationen
zu FPLs; Du hattest ja eine Liste von Informationen zu FPLs
gemailt, die wohl aus einem Buch oder Vorlesungsunterlagen stammen.
Folglich müsste das also Informatiker-verständlicher Jargon sein,
aus dem heraus Du verstehen können müsstest, was FPLs sind,
wie sie arbeiten.
Da diese Vorgehensweise offensichtlich auch nicht hinreichend war,
darf ich dann wiederum feststellen, daß meine Erklärungen vielleicht
garnicht so schräg waren, wie man vermuten könnte, sondern daß das
Problem einer zu abstrakten Wissensvermittlung ohne Praxisbezug
zu quasi kaum nutzbarem Wissen führt.
Mit anderen Worten: Das beste Vorgehen, mit der Sache weiter zu kommen
ist, daß Du Dir eine FPL installierst und es ausprobierst.
Was meine Erklärungen zum Thema angeht: Die Features wie higher-order
Functions (functions als Variablen) habe ich angeführt, ebenso einige
andere Dinge. Wenn das nicht gleich verständlich ist, liegt das
auch daran, daß man eben *radikal* umdenken muß.
Es ist eben ein größerer Unterschied in der Denke zwischen
imperativer (non-OO oder OO) Programmierung und funktionaler
Programmierung. So Sachen wie "diese Daten gehören dem Objekt",
also "Datenschutz" sind in OO notwendig, weil man da auch
imperativ arbeitet, also variablen Werte zuweisen kann (mehr
als einmal).
Bei FP geht das nicht: man bindet einmal einen Namen an eine
Value und damit ist der Fall gegessen. Man kann sie nicht ändern.
Und man hat immer das Prinzip, daß man "Variablen"(name-cvalue-bindings),
die man "weiter innen" in einem Konstrukt benutzt nur in diesem Scope
vorliegen hat. Das Einzige, was man von weiter innen gelegenen
Konstrukten zurück bekommt, ist eben der Wert des gesamten
Ausdrucks.
Was die Seiteneffekte betrifft: ohne diese kannst Du in
C/Java/C++ garnicht arbeiten, die gehören zum Arbeitsprinzip
dazu (oder, falls Dir ein Gegenbeispiel dazu einfällt ;-)).
Also kann man sie auch nicht nicht nutzen.
Selbst wenn man's könnte, hätte man das Problem, daß
man, wenn man wollte, es nicht zu nutzen, nicht daran gehindert wird,
es doch zu tun.
(OK, wenn Du den Satz nicht verstanden hast, macht's nichts...;-))
[...]
> > Und Algebraische Datentypen?
>
> Kenn ich nicht. Was ist das?
Also sowas, was man braucht, um Syntaxdiagramme
darzustellen/nachzubilden/zu implementieren.
Quasi die Entsprechung 'ner Syntax/BNF.
(Soweit in meinen nicht-Informatiker Jargon...)
[...]
> > > > 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.
(kurzes!) Beispiel möglich?
>
> > > > 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.
Perl kann keine BNFs per eigener Sprachsyntax analysieren.
Es gibt Module, ja.... aber eben ist das kein Sprachbestandteil.
(Und auch kein Perl-Standardmodul).
In Perl muß man das selbst programmieren, oder ein Modul nehmen.
In FPLs hat man Algebraische Datentypen, die einem solche
Konstrukte schon mitbringen. Da definiert man einen Typ,
der die Syntax abbildet. Sieht ähnlich aus, wie yacc-Konstrukte.
(Achtung, ich habe nicht gesagt, es ist das selbe, aber es
hat damit Ähnlichkeit... also "yacc-like", aber vorsicht...)
>
> > 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.
In OCaml kann man mit den Algebraischen Datentypen eine
Syntax quasi direkt nachbilden.
Lexer/Parser sind obendreinin OCaml's Standardlibrary auch
mit dabei (ocamllex und ocamlyacc).
>
> > > > > 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.
OK: Ja, man kann mit weniger Code auskommen. Man braucht z.B.
diese vielen Deklarationen nicht. Die Typen werden eh automatisch
erkannt.
function x -> x + 3;;
Das ist automatisch eine Int-Funktion, denn eine für floats
sähe so aus:
function x -> x +. 3;;
bzw mit Namensverhabe:
let myadd3 x = x + 3;;
das ist kürzer als in C:
int myadd ( int x )
{
return x + 3;
}
und man muß auch nicht sagen, daß es ein int ist, was
als Arg. und Rückgabewert erwartet wird. Das ist schliesslich
aus der Funktionsdefinition ersichtlich.
Und wenn es dann erst mal an sehr umfangreiche
Funktionen geht, wird das eben noch klarer.
Während man in C folgendes machen kann:
int b ()
{
return M_PI;
}
int a()
{
float x;
x = 12 * b();
return x;
}
und 36 als Rückgabewert von a() erhält, geht sowas eben nicht
in FPLs.
Man sieht auch, daß das ganze Deklarieren entfallen kann.
(Ich hoffe, das Beipiel warnicht zu trivial, aber ich will
die Mail nicht weiter aufblähen.)
>
> > 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.
Klar. War so gemeint, daß ich die Sprache nehme, die besser
geeignet ist, ein Ziel zu erreichen.
Und wenn man erst drei Monate in C codiert, um festzustellen,
daß da eh ein Designfehler war, statt das in drei Wochen mit
Perl zu machen, dann war das er falsche Ansatz.
(Rapid Prototyping, um mal wieder wichtig klingende Worte zu benutzen.)
Also lieber eine Sprache. Aber wenn's wirklich irgendwo
bottleneckt, sollte man sich nicht necken lassen und
ggf. auch ne Ebene tiefer greifen. Aber eben nur, wenn
wirklich notwendig.
> Überhaupt kann man Sprachen nur schwierig
> wechseln. Ich verwende halb Java, halb C++, ist schon schlimm
> genug.
Sind die (C++ und Java) sich nicht ähnlich genug, um auf einen
Wechsel vollkommen verzichten zu können?
BTW: Man sollte zwar möglichst bei einer Sprache bleiben,
wenn es geht; aber wenn man mit zweien besser bei wegkommt,
nimmt man die zwei natürlich.
Das ist doch der Ansatz von Scripterei (Tcl/Perl/Shell,...):
Man hat was für die unteren Ebenen (C, Assembler) und was
für die höheren Ebenen.
(Da gibt's nen Aufsatz von Stroustroup zu dem Thema, dem
Tcl-Entwickler/Erfinder, der das gut erklärt.)
Im Prinzip Schichtenmodell.
Und wenn man richtig abstraktes, komplexes Zeugs bearbeiten
muß, nimmt man eine FPL. Hat man überwiegend String-Krams
zu machen, den man mal eben "ad hoc" zusammen bauen kann
(ach ja, wie schnell man sich doch täuscht und das Projekt
wird doch umfangreicher...) kann man auch Perl nehmen.
(Ja, und für GUI evtl., Java? ... Ich arbeite eh lieber mit
shell und xterm als mit GUI, deswegen fällt Java eh aus meinem
Focus heraus...)
> Perl ist nett für kleine Scriptchen, so bis 1000 Zeilen
> vielleicht, mehr braucht man meist nicht "zwischendurch".
So war das auch gemeint mit Perl statt C, wenn man Perl-like
Patternmatches nutzen will...
> Perl
> also für die Helferchens und so.
Naja, man kann auch schon Applikationen damit bauen.
Habe ich auch gemacht; War garnicht so schlecht mit
Perl (mit OO); aber so richtig prickelnd war das
nicht. Aber jedenfalls kommt man schneller zu Ergebnissen
als in C.
> Externe Sachen (CGI Interfaces)
> kann man ganz gut in Perl machen (hab ich auch), aber innerhalb
Ja. Entweder direkt, oder CGI.pm. => Apache: modperl ist fein :)
> einer Anwendung (GUI oder Server) geht das nicht wirklich schön.
Im Apache als modperl ist's aber recht flott.
> Kann man natürlich machen, meistens überwiegen aber die
> Nachteile.
Welche?
In welcher Applikation?
BTW: Perl hat auch eine C-Schnittstelle; ist aber fast schlimmer
als die von Tcl. (oder eher ohne "fast"...)
[...]
> > 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).
Um die Seiteneffekte kommt man nicht umhin.
errno ist nervig, wenn man mit plain C arbietet.
Man kann natürlich wrapper-Funktionen bauen
(wie Stevens empfiehlt; ok, die Idee ist schon ganz nett), die
die Fehlerabfrage verbergen. Aber richtig Spaß macht das nicht.
Daß alle Leute schlechte Vererbungshierarchien benutzen, sei
mit obigem nicht gesagt. Aber meist wird zuviel vererbt und zuwenig
aggregiert. Und dann hat man den Salat. ;-)
>
>
> > [...]
> > > > 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.
Falsche Syntax; hätte heißen sollen
` Finde ich nicht "na und". '
Wieder Kommunikationsproblem.
[...]
> > > > > 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".
Ja, das habe ich auch nie bestritten.
Das müsste man über Wrapper-Funktionen lösen, aber das weißt Du
ja selbst. Ich denke, wir haben auf voller Linie aneinander
vorbei geredet.
[...]
> [...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.
Dann bitte Zitat aus dem C-Standard anbringen, der das Thema
erläutert. Und ausserdem ist zwar im K&R nicht alles
erwähnt => nicht Maß aller Dinge stimmt diesbezüglich.
Was dort aber drinsteht sollte korrekt sein => also eben
doch implementationsabhängig, wie const gehandhabt wird.
(Also eben doch auf Sand gebaut; const kann, muß aber nicht
hilfreich sein, eben wegen der Implementationsabhängigkeit
btw: gutes Thema für dclc.)
>
> > > > 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?
Im Bereich abstrakter Verarbeitung von Daten (higher-Order functions,
algebraische-/abstrakte Datentypen, Modulsystem, Patternmatching
mit Prüfung der Vollständigkeit), saubere Schnittstellen,
keine Coredumps, vorhersagbares Verhalten, weil man nicht mit
Seiteneffekten arbeitet, gut lesbarer Code, weil man nicht
ständig mit irgendwelchen nervigen Zeilen von Deklarationen
zu kämpfen hat, die einem den Blick auf's Wesentliche des Programms
verhindern, deshalb hat man defacto-Möglichkeit für "rapid prototyping";
der funktionale Ansatz und die rigide Typprüfung animiert einen
zu gut durchdachtem Design, denn "der cast für alle Fälle" hilft
einem nicht weiter, ...
(Sicherlich gibt's noch weitere Argumente, bestimmt findet man die
z.B. in comp.lang.functional :))
>
> > GUI: via Tk.
>
> Gibt einen Tk Port dafür? Nicht schlecht.
LablTk heisst dat Teil. hab ich noch nicht ausprobiert,
aber Codebeispiel sahen schnucklig aus. :)
Habe gestern mal die (nicht-Tk) graphics-Lib (Ocaml-Standardlib)
ausprobiert. Ganz schnuckelig. Arbeitet wohl direkt auf der
XLib. (Auf Windows läuft diese graphics-Lib auch, konnte ich
aber mangels Windows nicht ausprobieren, bin ich aber auch nicht
besonbders betrübt drüber ;-))
(=> Somit hat man also einen Zugang zur Xlib/den wichtigsten
Funktionen der selbigen auf OCaml-Ebene. Da kann man dann
wirklich heftiges Zuegs mit machen. Werde das demnächst mal
ein bischen genauer unter die Lupe nehmen. Da wird sich dann
vermutlich mal was draus ergeben, was man auf www.belug.org mal
auf ftp legen kann - als Codedemo bzw. kleine, schnuckelige
Graphik-Applikation. So macht das Programmieren wieder Spaß. :))
>
> > ORB (a la Corba?) => Libs.
>
> Es gibt also OCaml LIbraries für Corba funktionen, ein language
> Mapping etc? Nicht schlecht. Überrascht mich ehrlich.
Nicht in der Standardlib von Ocaml.
Es gibt aber ein recht fettes Lib-paket extra. Da ist so viel
Zeugs drin, daß man das kaum für möglich hält.... auch PostScript-
Zeugs.. :)
>
> > 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.
Ja, isses aber nich. ;-)
>
> > let _ = establish_server server (ADDR_INET (inet_addr_any, 9876))
>
> sieht auch sehr nach C aus.
Soso.
>
> > #########
>
> Na ja, egal, weiß eh nicht, was Du damit sagen willst.
@@@@@@
Ist der Verständlich? ;-)
[ Primzahlen/ Sieb des E.]
> > Eine entsprechende Eimplementierung in einer IPL wäre
> > sicherlich schwerer zu entziffern.
>
> Übungsfrage/Gewohnheitsfrage.
Bedingt.
1.: Text/Code, der nicht direkt den Algorithmus betrifft stört
das Auge immer; Gewohnheit mag helfen. Aber auch
Quelltext unterliegt typographischen Gegebenheiten =>
Unnütze Informationen lenken vom Wesentlichen (dem Algorithmus)
ab.
2.: Schon mal den eigenen Code nach 1/2 oder 1 Jahr wieder
ausgebuddelt und angeschaut?
3.: Mal fremden Code angeschaut? Persönliche Geschmäcker lassen
fremden Code oft unleserlich erscheinen. Es gibt Programmierer,
die codieren so, daß es aussieht, als hätte man ein Binärfile
durch uuencode geschickt. ;-)
>
> > Man wird die Ergebnisse sehr schnell vorliegen haben.
>
> Sicher? Glaube ich nicht, ist doch extrem rechenaufwendig.
a) Schnell vorliegen, weil man nicht ewig implementiert
b) auch schnell, weil die Verarbeitung schnell genug ist
c) Gute Grundregel der Programmierung:
1. Löse das Problem (Bed.: Löse es so, daß Du den Code verstehst)
2. Optimiere, falls notwendig, und zwar *nur* falls notwendig (Bottleneck)
(ansonsten wende Dich sinnvolleren Aufgaben zu)
Zu c) gilt zusagen, daß es imperativ formuliert ist, also
die Abarbeitungreihenfolge von Bedeutung ist und
es gilt, zuerst 1) zu befolgen und dann 2).
Eine funktionale Beschreibung von c) habe ich jetzt
gerade nicht vorrätig. ;-)
>
>
> [... 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.
Welcher MUA?
(Neugier!)
[...]
> > 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.
Weiß nicht. Würde mich nicht wundern, wenn es auch dafür
schon Schnittstellen gibt. ;-)
Notfalls fork/exec?
Ok, Sockets...
Nee, man optimiert normalerweise eh erst, wenn's eng geworden
ist. Manche Sachen machen sich aber möglicherweise in C
bzw. gar Assembler besonders gut.
-> Schrieb letztens in comp.lang.functional einer, er habe durch
den Einsatz von Assembler auf einem G4 PowerMac durch Nutzung
des Vectorprozessors ein speedup von Faktor 16 gehabt.
Das macht dann schon was her. :)
>
> > 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?
Ja, ich denke mal.
(Ocaml hat ebenso eine C-Schnittstelle; habe ich noch nicht
ausprobiert, soll aber auch prima sein. Kommt alles zu seiner Zeit.)
>
> > > 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?!
Vorne rechts. Da ist's ok. ;-)
[...]
> > P.S.: Hat das noch Sinn, sich durch so langes Textzeugs
> > durch zu kauen (Autsch!;)).
>
> Siehste, ist nicht gesund :)
Habe Erbarmen, ich konnt's trotzdem nicht lassen. ;-)
Ciao,
Oliver
Mehr Informationen über die Mailingliste linux-l