[linux-l] LinuxScript?
Oliver Bandel
oliver at first.in-berlin.de
Do Apr 4 22:21:46 CEST 2002
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:
> > > * Oliver Bandel wrote on Mon, Apr 01, 2002 at 19:55 +0200:
> > > Man! Deshlab liegt dieses new doch im Directory-Namespace. Sieht
[...]
>
> > [...]
> > > > Perl-Programmierung ist größtenteils prozedural; man
> > > > kann auch OO etwas beimengen.
> > >
> > > "beimengen" ist untertrieben.
> >
> > 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.
Als ich mit Perl anfing, habe ich genauso gedacht.
Als ich mir die FPLs mal angeschaut habe, sah das plötzlich ganz
anders aus.
>
> > > 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.
Die Unterlagen aus Deinem Studium waren offensichtlich nicht dazu
geeignet, Dir die Unterschiede aufzuzeigen.
Das finde ich auch, wenn ich meinen Ausgangspunkt betrachte, der Frage
nach der Verfügbarkeit von AppleScript-ähnlichen Sprachen auf Linux,
auch etwas überzogen. Wenn es Dich wirklich interessiert,
lies in comp.lang.functional.
Aber um ein wesentliches, interessantes Merkmal heraus zu picken,
das die Programmierung elegant macht, sei da z.B. noch einmal
die Funktionen als first-class citizens der Sprache genannt,
oder die Zusammensetzung von Funktionen (function composition)
ist etwas geradezu herausragendes.
In so einer Einfachheit wie in FPLs kann man das in imperativen
Sprachen nicht machen. Das alleine wäre schon ein Grund, sich
diese Sprachen anzuschauen.
Aber auch die Algebraischen Datentypen sind in konventionellen
Sprachen wohl nicht vorhanden, sowie weiteres.
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. Zwischen
In- und Output steht die Funktion. (Deshalb ist sie auch äquivalent
zum Ergebnis und deshalb kann man Funktionen auch als Parameter
für andere Funktionen übergeben oder als Ergebnis Funktionen zurück
bekommen.)
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.
Da verhält sich eine Funktion plötzlich ganz anders als beim letzten
Aufruf. Und dann gehtdie Fehlersuche los und die Projekte
gehen den Bach runter...
Funktionale Programmierung hat weiterhin den Vorteil, daß man
die Programme mathematisch (vollständige Induktion) auf
Korrektheit prüfen kann. Und man kann einen Algorithmus mithilfe
der der FP zugrunde liegenden Theorie (Lambda-Kalkulus) umformen
und so ggf. besser formulieren (da gibt's Regeln zur Konvertierung).
Im Allgemeinen bieten die FPLs mächtigen Sprachumfang mit einem
excellenten Klassensystem, Modulsystem, etc.
Noch ein schönes Schmankerl: OCaml z.B. erkennt automatisch den Typ
eines Ausdrucks. :)
>
> [1]
> > > > Nein. Ich kenne Perl recht gut. Letztlich ist es ein enhanced C
> > > > plus etwas OO.
>
> > > nachladen/überschreiben zur Laufzeit usw. Dazwischen liegen
> > > WELTEN.
> >
> > Ich weiß.
> > Aber der Unterschied zu den FPLs ist so groß, daß diese
> > Welten zusammenschrumoen auf Sandkorngröße...
>
> Welcher Unterschied?
s.o.
und weiteres
Wenn Du wirklich daran interessiert bist und mich nicht nur
trollender Weise provozieren willst, dann liest Du Dich
selbst in die Materie ein.
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.
("kann mir nicht vorstellen, daß ... erlär mal...")
Darauf habe ich keine Böcke.
FPL-Gurus findet man in comp.lang.functional, in der
OCaml- und der Haskell-Mailinglist. Die können Dir das
auch sicherlich noch besser erklären als ich, denn die
Leute forschen teils auf dem Gebiet, oder haben einfach
mehr Erfahrung mit FPLs. Manche von ihnen entwickeln
die Sprachen, einige habe auch die Innereien von Java
mitentwickelt; wenn die sich äußern, sollte man die
Ohren spitzen.
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.
>
> [2]
> > > > Ja, Perl und C sind im Prinzip das Gleiche.
> > > > Das ist es ja, was ich meine...
> > >
> > > Irgentwas hast Du nicht verstanden ;)
> >
> > Irgendetwas hast Du ncith verstanden.Schau Dir nochmal
> > ganz genau an, was FPLs können, und was die Programmierung
> > unterscheidet.
>
> Du hättest es auch einfach mal schreiben können. Offensichtlich
> war Dein Link der letzten Mail nicht ausreichend.
Ich habe beim letzten mal den Link zum OCaml-Buch geschickt.
Das gibt's auch als html-version, falls Du keine Böcke auf's
pdf hast.
Und dort sind schon sehr gut einige Vorzüge erklärt.
Sich durch 15 k Mailtext mit drei oder mehr Quoting-Ebenen
zu kömpfen macht keinen Spaß.
Ich wollte nur sagen, was mir an der einin oder anderen
Sparache gefällt. Nach Dauerthraead ohne Ergebnis steht mir der
Sinn nicht. 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.
Wenn's Dir um die Sache geht, lies demnächst auf comp.lang.functional
mit. Ich könnte auch nochmal nach URLs von interessanten Papers
schauen, aber das wars dann auch schon.
>
> > > Weil es C++ gibt.
> >
> > Lohnt sich der Lernaufwand nicht. :)
>
> Immer diese unbegründeten Aussagen...
Ebenso wie Deine.
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.
Wenn Du meinst, es ist alles Kack, was ich hier erzähle, ist es
Dein Problem.
Kann ja nicht jeder Mensch Interesse daran haben, wirklich
immer dazu zu lernen. Tja, die Menschen sind eben verschieden.
>
> [...]
> > In dem Buch dazu steht uch ein bische was zum OO
> > als Vergleich Ocaml vs. Java.
>
> Und was denn nun?
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.
Also: Lies selbst und entscheide selbst. Wenn Du dann immernoch
denkst, daß das alles kack ist, laß es mich wissen, ich lerne
gern' dazu.
Anonsten wirst Du ja vielleicht tatsächlich (funktionales) Blut lecken... :)
[...]
> > > Ja klar, wenn sie sich hinsichtlich von Typen unterscheiden.
> > > Müßte doch bei funktionaler Programmierung ähnlich sein? 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)?
>
> 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
Hast Du eine spezielle Haskell-Frage?
>
> > > In C kann man ja auch sauber arbeiten. Machen eben nur nicht
> > > alle...
> >
> > Du argumentierst so, als wenn ich sagen würde: Auch in C hat man
> > Typprüfung, wozu brauche ich C++?
>
> Damit der Compiler mehr Fehler schon bei der Compile-Zeit finden
> kann. Das wird in Ada noch stärker gemacht. Ganz interessant, es
> hilft wirklich öfter mal.
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.)
>
> > Warum kann man in C++/Java casten?
>
> Man kann in Java 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?
> 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? Ist doch unsauber.
Wenn man ein short braucht, nimmt man ein short.
(Ja, nimmt man in der Praxis oftmals nicht, aber das ist
ja auch eines der größten Probleme in der Programmierpraxis:
man macht oftmals, was man lieber nicht machen sollte.
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...)
> > Dann kann ich auch gleich C nehmen und alle Pointer
> > als void* deklarieren. Dann spare ich mir die
> > Casterei. :)
>
> 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.
Dann stimmt das auch mit den Schnittstellen.
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?
-> Auf casts verzichten und Funktionen nutzen, die entsprechende
Typen haben.
>
> 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?
int? Welche Größe hat der int? (btw: der darf aber so nicht heissen)
=> Implmattaionsabhängig in C. Es gibt nur Mindest-Größe laut
C-Standard.
Wozu überhaupt solch ein switch/case-construkt?
Was ist mit mod? Oder ausmaskieren?
Du willst Dein Argument stützen, indem Du ein Gegenbeispiel
widerlegst? Ich kann dem Switch-case da auch erst mal nichts
sinnvolles abgewinnen.
>
> > > > - ...diverse weitere Vorteile, u.a. auch aus den Sachen,
> > > > die mit dem pattern-Matching machbar sind,
> > >
> > > Kann Perl auch als Sprachelement, C als Funktion...
> >
> > Nein. Pattern Matching ist anders gemeint und viel
> > umfassender.
>
> 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?
> Das ist sehr
> umfassend (nämlich so umfassend, wie eine reguläre Grammatik, und
> mit einer solchen ist theoretisch schließlich jedes endliche
> System mit endlich vielen Möglichkeiten [also auszählbare Systeme]
> darstellbar).
>
> Wundert mich sehr, daß diese Begrifflichkeit hier für eine
> Listen-Selektion verwendet wird. Aber ist ja egal.
Selektion auf's Eingangsargument, im speziellen Falle halt
eine Liste.
>
> > 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.
Aber FPLs arbeiten anders. Alles ist ein Ausdruck, der
evaluiert wird, keine Seiteneffelte usw.
Das Pattern-Matching ist Typensicher; in Perl mußt Du Deine
Argumente selbst auf Konsistenz prüfen.
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.
>
> > > > 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?
Da ich kein C++-er bin, reichen mir die Klagen anderer Leute
und die Aussicht auf das, was OCaml mir bereit stellt.
Parametrisierbare Klassen klingt jedenfalls interessant.
Du kannst das sicherlich besser einschätzen, als ich,
da Du ja wohl Informatik studiert hast?
Ich werde mir das Wissen noch aneignen, also kann ich Dir
noch nichts zu parametrisierbaren Klassen erzählen.
Schau's Dir an.
Einfach mal unter http://www.ocaml.org gucken, was da
noch so alles zu finden ist.
Auch interessant ist http://www.haskell.org/
Oder http://www.erlang.org/
Erlang ist eine FPL, die von Ericcson entwickelt wurde und auf
vielen kommerziellen Groß-Produkten zuverlässig läuft.
Erlang's Spezialgebiet: Concurrent Programming und verteilte Progr.
Das wiederlegt auch, daß FPLs nicht für kommerzielle Produkte
tauglich wären.
>
> > Kein Vergleich.
>
> Begründung vermißt.
parametrized classes
Sollte Dich neugierig machen.
Bin ja selbst relativer noch FPL-neuling, also kann ich Dir
auch nicht alles runterbeten, was man in Deinem Studium
vergaß Dir mitzuteilen. ;-)
>
> > > > mit abstrakten Datentypen,
> > >
> > > Na gut, C nu nicht, aber C++, und Perl fast :)
> >
> > Nein. Murks.
>
> Was? Abstrakte Datentypen in C++? Geht doch prima!
Wie? Libs?
Und Algebraische Datentypen?
>
> > 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.
Und wie macht man da algebraische Datentypen?
>
> > Wie machst Du das, wenn Du eine BNF hast in C++ oder Perl
> > oder Java?
>
> Einen regulären Ausdruck anwenden?
Häh?
In Perl? C++?
Wie? Library?
>
> > > 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?
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.
>
> > jaja, es gibt Libraries... aber eben sind Libraries
> > nicht die Sprache selbst... und selbst mit Libs
> > wird's in perl schneller gehen.
>
> 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, eben die VORAUSSAGBARKEIT DER
ERGEBNISSE. FP ist sauberer, übersichtlicher als
C/C++/Java-Gefrickel mit Seiteneffekten, errno-Nerv,
kruden Verebungshierarchien, ...
[...]
> > 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. Aber ok, ist ein anderer Punkt, ok.
>
> > > Kann mir nicht vorstellen, daß es sich ansatzweise mit Perl
> > > messen kann.
> >
> > 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.
Inwieweit man auch krudes machen kann, ähh, räusper.
Python's Modulsystem/OO scheint mir auf den ersten Blick
sauberer designt zu sein.
Schau's Dir am besten selbst mal an, bin kein Python-er,
habe nur einen ersten Eindruck von der Sprache. Reicht,
um sie in die Liste potentieller weiterer Sprachen, die ich noch
lernen will, einzureihen.
>
> > [...]
> > > > Auch in OO-Sprachen hat man die Macht die return-Value
> > > > zu überschreiben.
> > >
> > > 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.
Wollte eigentlich eh bloß wissen, ob's hier Sprachen a la
AppleScript unter Linux gibt. Deswegen bin ich auch nicht
besonders darauf erpicht, ewig lange Sprachfeatures auszudiskutieren.
>
> > Auch in C kann man Daten kapseln. Greift man eben
> > nicht direkt auf die Daten zu, sondern hat Funlktionen,
> > die einem Werte zurückgeben. So what?
>
> Ja, und nu?! Darüber habe ich doch letzens eine lange Mail
> geschrieben? Genau darüber, mit genau dieser Aussage:
> Datenkaselung oder Funktionen, die die Instanz kennen, zu der sie
> gehören.
Ja, fein.
Ich denke, wir lassen das an der Stelle. Wir reden aneinenader
vorbei.
Und beide sind wir schon lange OT.
>
> > Den Wert, den man bekommt, kann man aber nach belieben ändern.
> > Bei FPLs geht das nicht. Die Var. behalten ihren Wert.
>
> Muß man eben const davor schreiben. Ist doch kein elementarer
> Unterschied, ob ich nur imutable vars hab, oder nicht.
const in C nützt nur nicht immer so viel: Das Verhalten bzgl.
Überschreibens einer const-Var ist implementierungsabhängig.
(Btw. in Funktionsdeklarationen wird const zwar von gcc
geschluckt, da ist aber in K&RII nichts zu finden, was dem
eine sinnvolle Interpretation gibt).
=> Auf Sand gebaut.
>
> > Habe keine Zeit, die Mail noch weiter auszudehnen,
> > weil ich gleich zum Arzt muß (Weisheitszähne rausnehmen lassen...).
>
> Ohh, na viel Spaß. Hab den Kram zum Glück hinter mir, fand ich
> nicht wirklich lustig...
Aha.
>
> > [...]
> > > > Hättest Du es Dir näher angeschaut, hättest Du aber
> > > > vermutlich schlechte laune, wenn Du mit C++/Java arbeitest.
> > >
> > > Wieso, in Java und C++ gibt's schicke Frameworks mit massig
> > > Mannjahren Entwicklungsleistung. Die möchte ich nicht
> > > nachschreiben müssen... Schon allein so ne CORBA ORB
> > > Implementierung ist extrem komplex... Nee, da bin ich verdammt
> > > froh, daß ich den Kram fix und fertig kriege und benutzen kann!
> >
> > 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.
GUI: via Tk.
ORB (a la Corba?) => Libs.
Echo-Server in OCaml:
#########
open Unix
let server ic oc = Printf.fprintf oc "%s\n" (input_line ic); flush oc
let _ = establish_server server (ADDR_INET (inet_addr_any, 9876))
#########
>
> > > > Man kann z.B. mit der Funktion filter folgendes nettes machen:
> > > >
> > > > filter isEven [2,3,4,5]
> > >
> > > Ist bloß wieder wenig Performant, weil man zu viele Listen
> > > kopieren muß.
> >
> > Nö.
> > Steht da was über die Implementierung in der Syntax drin?
>
> 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?
>
> > > > filter isSorted [ [2,3,4,5],[3,4,44,7],[],[4] ]
> > > >
> > > > gibt alle Listen zurück, die sortiert sind....
> >
> > No.
>
> Deine unbegründeten Aussagen helfen der Diskussion wirklich nicht
> weiter...
Das No war eh an die falsche Stelle gerutscht, habe gerade nochmal
nachgeschaut. Sorry, war in Eile.
Was die Sprache angeht: ob das intern mit Elemente Kopieren oder über
Referenzen gemacht wird, soll dem programmierer egal sein.
Was den Algorithmus angeht, mag der anders effizienter gehen.
Das Beispiel stellte Spracheigenschaften dar, z.B. Haskell's
List Compreehension.
Wenn man "mal eben" ein paar Primzahlen braucht, kann man in
Haskell das Sieb des Erastothenes so implementieren:
#########
primes = sieve [2..]
sieve (h:t) = h : sieve [ x | x <- t, x `mod` h /= 0 ]
#########
Das hat Vorteile: Man kann hier den Algorithmus erkennen.
Eine entsprechende Eimplementierung in einer IPL wäre
sicherlich schwerer zu entziffern.
Man wird die Ergebnisse sehr schnell vorliegen haben.
Was Recursion angeht, ist die nicht immer langsamer als eine
iterative Lösung. Es gibt tail-recursion, die ist recht effizient.
Warum? Das kannst Du mir sicherlich besser erklören als ich Dir.
Also: Warum ist tail-recursion effizient?
>
> > > sort ( 2, 3, 4, 5 )
> > >
> > > Man kann sich ganz einfach auch ein sort machen, was Referenzen
> > > erwartet und dann schreiben:
> >
> > referenzen brauchst Du dann abrer nicht mehr....
>
> Referenzen sind ja nur eine schnelle, effiziente Methode, z.B.
> Listen zu übergeben. Vermutlich macht OCAML das auch nicht
> anders. Spart das Kopieren.
Aber um solche Details will man sich als Programmierer nicht
immer kümmern. Wenn man funktional programmiert, kümmert einen
solch Zeugs nicht.
Da ich ganz gerne aus allen Welten die Vorteile nutzen will,
ziehe ich auch derzeit OCaml Haskell vor. Da habe ich
funktionale, imperative, objekt-orientierte Programmierung
zur Auswahl. (Funktionale bevorzugt.)
>
> > => Frickel.
>
> Warum? Begründung fehlt.
Referenzen sind nervkram, um den man sich nicht kümmern
will, wenn man nicht muß - jedenfalls, wenn man nicht
ausgerchchnet gerne mit Pointern rum spielt.
Wo sind da saubere Typen in Perl?
Btw: Nichts gegen Perl, nutze ich selber sehr gerne. Aber
Perl kann eben auch nicht alles und hat eben nicht
nur Vorteile, nur weil es schnuckliger als C ist.
>
> > [...]
> > > > Oder mit der Funktion map kann man eine Funktion auf
> > > > die Listenelemente anwenden, ....
> > >
> > > Heißt in Perl auch map :)
> >
> > No. Perl's map is a draft. :-)
>
> Warum? Begründung fehlt.
Es gibt viele Gründe.
Man kann z.B. keine Funktionen zurückgeben (evtl. kann man
da auch wieder mit Referenzen frickeln => Typsicher?).
Auch ansonsten sind die Listen selbst nicht einheitlichen
Typs.
Klar, hat manchmal Vorteile, daß man da alles zurück geben
kann. Aber wenn man C++ und Java wegen der Typprüfung
C vorzieht, kann man FPLs wegen noch strikterer Prüfung da
nicht einfach ignorieren, sonder müßte dies doch begrüßen.
(Auch hier - wie *immer* in Perl & Co. - wieder: Man kommt um das
Problem der Seiteneffekte nicht herum. Das taucht halt immer
wieder auf.)
>
> > > > Diese Möglichkeit ist echt wat feinet. :)
> > >
> > > Ja, erinnert mich sehr an Perl.
> >
> > Ist'a aber nicht.
>
> Context verloren, sorry.
dito. ;-)
Ich finde diese mail einfach zu lang, um hier noch durchsteigen
zu können, was wan wer wie gesagt hat.
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. :(
Und's ist einfach zu lang (braucht auch viel Zeit zum Antworten;
vielleicht wäre das bei'm Bier besser zu beguatschen ;)).
>
> > [...]
> > > > da die Freaks loslegen, hört man immer wieder davon, wie
> > > > kruder, unausgegorener Kack doch C++ und Java sind....
> > >
> > > Das hört man i.d.R. von Leuten, die C++ und Java nicht kennen.
> >
> > Die Leute, die ichmeine, kennen's aber sehr gut.
>
> Wen interessiert das? Wer Java als "unausgegorener Kack"
> bezeichnet, hat da wohl eher weniger nachgedacht und/oder
Unausgegorener Kack ist meine Translation.
> etliches nicht verstanden, schließlich stecken in Java sehr viele
> gute Ideen, Erfahrungen und Konzepte.
Naja, einige der FPL-Leute haben teils selbst an Java mitentwickelt
und haben FPL-Know How einbringen wollen, was teilweise ging, aber
das war nicht immer machbar.
>
> > > Wie bereits gesagt, die Sprache hängt vom Problem ab. Und ich
> > > kann mir nicht vorstellen, eine interaktive GUI mit Grafiken etc.
> > > in einer funktionalen Sprache zu machen...
> >
> > Geht.
>
> "Geht" auch in Assembler. Geht es *gut*? Gibt es einen Orb? Das
> sind doch interessante Fragen.
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?
genauso, wie man Low-level-Zeugs in C oder Assembler machen
kann und die abstrakteren Dinge mit einer FPL.
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.
Btw: Ob's ne GUI/ORB gibt, sind nichjt für lle Leute die
interessanten Fragen. Nur, wenn man ne GUI braucht. :)
>
> > Was Du für OO reklamierst, gilt auch für FPLs:
> > Man kann's nicht wirklich "mal eben" nachbauen.
>
> Bloß das ich es begründet habe.
>
> > So, jetzt muß ich los.
>
> Na, dann: schon mal gute Besserung!!
Danke.
Die haben mir gleich alle 4 Weisheitszähne gezogen.
Naja, muß ich nur einmal durch. Weitere Zähne von
der Sorte habe ich nicht. ;)
So, jetzt reichts aber mit der Mailerei.
Ist doch ganz schon viel Text. Wollte heute auch noch
was anderes tun, as nur am Rechner zu hängen.
Ciao,
Oliver
P.S.: Hat das noch Sinn, sich durch so langes Textzeugs
durch zu kauen (Autsch!;)).
Mehr Informationen über die Mailingliste linux-l