[linux-l] Re: [linux-l] [OT (?)] FPLs und Anderes Gesülze (Re: [linux-l] LinuxScript?)

[Oliver Bandel]

On Fri, 5 Apr 2002, Steffen Dettmer wrote:

> * Oliver Bandel wrote on Fri, Apr 05, 2002 at 16:27 +0200:
> > 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:
> > > > [on this ident level]
[...]

(hoffentlich klappt das mit den Einrückungen auch wirklich... ;-))


[...]
> > > 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.
> > 
> > Wenn Du willst, stelle die Frage nochmal bezogen auf das, was
> > Du wissen willst neu.
> > Ich kann mir nicht rauspicken, was Du wissen willst.
> 
> Na ja: wann möchte man denn nun Listen und Zahlen vergleichen.
> Wie kann man da sinnvoll Operatoren drauf definieren?

Man möchte eigentlich Zahlen und Zahlen vergleichen.
Man kann sich zwar auch andere Problemstellungen
ausdenken, aber irgendwie weiß ich halt nicht,
wie Du darauf gekommen bist, daß man Zahlen und Listen
von Zahlen vergleichen will.
Hattest Du wegen des Haskell-Codes irgendwie noch Fragen?



> 
> > ist.  ;-) Haskell überlädt nämlich Operatoren und ich darf mal
> > vermuten, 
> 
> Eben, sagen wir mal: nicht ideal, weil nicht intuitiv (ja klar,
> vieles ist nicht intuitiv, natürlich C allem voran :)).

Naja, vielleicht intuitiv, wenn man weiß, wieso das geht oder
gehen soll. Aber ich weiß garnicht, wo das Beispiel denn vorkommt.


> 
> > > 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.
> 
> Ja, hat eben so alles seine Vor- und Nachteile. Das ist's ja
> eben: nichts ist ideal, kommt immer auf das Problem an.

Ja. Nur ist's eben, daß wenn man eine Sprache auswählen will, weil
sie mit der Typisierung streng umgeht, und das als absoluten
Vorzug hält, als wichtiges Instrument, um zu verhindern, sich
in ewig dauernden Debugging-Arien auszumehren, dann sollte man
sich freuen, wenn es da Sprachen gibt, die noch strenger sind und
erwägen, auch diese einzusetzen.

Oftmals wird in Firmen deswegen auf immer nur eine Sprache gestzt,
weil man nicht in der Lage ist, die Schnittstellen sauber zu definieren.
Hätte man modularen Aufbau und saubere Schnittstellen, spräche
prinzipiell nichts gegen 10 oder nochmehr Programmiersprachen
in einem Projekt - daß man das aus anderen Gründen doch nicht machen
sollte, ist klar. Aber das Prinzip "wir nutzen nur xxx in unseren
Projekten" ist oftmals Folge von Dummheit und Fehlplanung.

Habe da schon die verschiedensten Dinge erlebt.
Von "Perl nicht nehmen, nur C", über "Perl ist ok, aber
kein Haskell/Ocaml",  bis zu der Umkehrung der
Einschränkung mit "Du solltest auch PHP nehmen, nicht nur Perl!".

In den ersten beiden Fällen war es Unwissenheit und Angst,
das Projekt nicht durchziehen zu können, im letzten Fall
war es Dillettantismus der Gesamtprojektplanung, so daß
PHP-Frickelei genommen wurde, statt Perl im Apache, obwohl
das im Prinzip möglich wäre.
Mit solchem Scheiß muß man sich in der Arbeitswelt rumplagen.
Sowas mache ich natürlich nicht lange mit.
Und deswegen ziehe ich Projekte auch am besten alleine durch:
Mir quatscht keiner rein (Sprache, Design, Zeitplanung) und
dann wird das auch was.

Man gucke sich dann an, wie es in Firmen läuft: Zu rigide Planung
oder garkeine Planung, alles mit netten Worten verdeckt,
und die Projekte semmeln regelmäßig ab: Termine platzen,
weil die teils wirklich zu knapp ghehalten sind, teils die Leute
ewig debuggen, statt sich vorher nen Kopf zu machen...

Naja, was reg' ich mich eigentlich auf... :(


> 
> > > ["int" cast in "char"]
>  [...switch(int)...] 
> > > > Statt dessen casten?
> > > 
> > > Ja.
> > 
> > Ich würde das mit if's abfragen und entsprechend zuweisen; dann
> > habe ich die Umwandlungsbedingung *explizit* im Code stehen.
> 
> Das ist ja analog zum switch. Wird bei langen, langweiligen
> Kolonnen schnell albern.

*Ein* if zum Abfragen des Bereichs:

if(value <= 0 || value >= 255) /* Kommentar, worum's hier geht */
  return dies_und_das_veraendern(value); /* dies_und_das ggf. erläutern */
else
  return value;


> 
> [...switch(int) again...]
> > > >  (btw: der darf aber so nicht heissen)
> > > 
> > > Warum nicht?
> > 
> > Weil's ein Schlüsselwort der Sprache ist.
> 
> :) Ach so, ja, wollte ja damit nur den Typ andeuten. Natürlich
> syntakisch falsch, klar.

;-)

> 
> > > Wie jetzt?
> > 
> > Bitmaske z.B.. => alle oberen Bits wegschnippeln.
> 
> Bitmaske auf reele Zahlen ist ja auch schon wieder unschön...

int's sind nicht reele Zahlen, sondern Ganzzahlen.
Oder meinst Du, weil int's keine Bitmasken sind?
Ok, so gesehen ist der Einwand ok.


> 
> > Auch dann hat man die Konvertierung expliziert (= lesbar
> > im Code, was man macht).
> 
> Na, dann wird ein int vorher eben in ein Byte konvertiert,
> bleibt implizit.

Was meinst Du?

[...]
> > Den Lambda-Kalkulus kann ich Dir nicht runterbeten, das lernt man
> > ja offensichtlich nicht mal im Informatikstudium.
> 
> Ich glaube, man vergißt es nur zu schnell ;)

Na, also sowas... wenn ich mir vorstelle, ich hätte die
die Kirchhoffsche Gesetze verlernt, nur weil das ein
paar Jahre her ist, daß ich sie gelernt und gebraucht habe...
...also wirklich... tse, tse, tse... wenigstens das Grundprinzip
solch wichtiger dinge sollte man noch im Schädel haben, so
daß man sich das mathematische ggf. herleiten kann...



[...]
> >  Klar, man kann auch ref() benutzen usw.,
> > aber man kann zur Laufzeit auch alles wieder umbauen.
> 
> Ja, das ist schön, kann man prima Sachen mit machen.
> 
> > Der Vorteil der Flexibilität fällt einem da auf die Füsse!
> 
> :) Ich mag das und mir fiel das noch nicht auf die Füße. Aber
> lassen wir das...

Ich mag das auch, und wenn man sauber arbeitet, kann man das
Gewicht des fallenden Gegenstands auch gut minimieren, aber
es ist ein prinzipielles Problem, das da weiterhin bleibt.




> 
> > 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".
> 
> Aha, also eine Liste von nur Ints oder nur Floats, ja?

Ja.
Haskell macht das auch so.
Aber in Scheme kann man gemischte Listen haben.


[...]
> > 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,
> 
> Ja, das ist eben eine andere Herangehensweise, die auch wieder
> Vorzüge hat. Es gibt einen Haufen nette Spielereien damit. Das
> kann man nicht von der Hand weisen. Natürlich hat das auch
> diverse Nachteile.

Die Spielereien sind nett, aber man braucht sie ggf. in FPLs
erst garnicht, weil man da andere (noch nettere) Sachen machen kann.


[...]
> > > 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.
> 
> Ja, schon klar.

Wieso schon klar? S.o.: Da sagst Du, daß das garnicht geht.
Wieso geht das denn nun doch?


[...]
> > > In C++ sind Klassen natürlich parametrisierbar (in verschiednen
> > > Arten).
> > 
> > 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.
> 
> Programmieren ist ja im Prinzip übersetzen eines Algortihmus in
> eine Programmiersprache.

Also ich fasse unter Programmieren auch das Designen.
Programmieren umfasst also meiner Auffassung nach
Design + Coding.

> Wenn ich eine GUI in C bauen soll, weiß
> ich aus Erfahrung, daß das umständlich wird, und nehme lieber
> Java.

Objective-C ist was feines. Ex-Java-isten, die auf
Objective-C umgestiegen sind, fragen sich immer wieder,
wieso sie sich so lange mit Java haben quälen lassen...


[...]
> Erst nachdem das Design fertig ist, kann
> man sich für ne Sprache entscheiden.

Ist natürlich auch immer eine Frage, wie gut sich ein
Design in einer Sprache handhaben läßt. Bzw., in
wieweit man das Design den potentiellen Möglichkeiten
(Programmierparadigmen) einer oder mehrerer Sprachen
angepasst hat.


[...]
>  [...] 
> > 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.
> 
> Ich denke, Funktionales Programmieren sollte man in prozeduralen
> Sprachen mehr oder weniger gut abbilden können. Natürlich muß man
> einige Sachen mehr machen, klar. 

Ist ebenso wieder eine Sache, inwieweit man OO in C
machen kann. Kann man auch abbilden... natürlich
können einige Sprachen mehr machen, klar.

(...)


[...]
> 
> > > Ach, soviel lernt man im Studium nicht über Praxis. Das ist ja
> > > hinlänglich bekannt.
> > 
> > Einschätzen der Qualität einer Sprache kann ich aber sehr wohl,
> 
> Da muß man aber höllisch aufpassen. Dazu:
> "Wenn Du als einziges Werkzeug einen Hammer hast, sieht jedes
> Problem wie ein Nagel aus."

Ich kenne mehrere Werkzeuge, Danke.


> 
> Sprich: Wenn Du Dich nur mit funktionaler Programmierung
> auskennst, sieht jedes Problem wie ein funktionales aus.

Ich komme aus der nicht-funkitonalen Ecke. Die kenne
ich recht gut. Nun schaue ich mir seit einem weilchen
die funktionale an und die gefällt mir noch besser.
Und damit ich beide Welten nutzen kann, wähle ich mir
eine Sprache, die mir beides bietet.


> 
> Manchmal hilft es vielleicht, wenn man ein Problem nicht
> funktional lösen kann (weil man z.B. Java benutzen muß), es so
> "funktional wie möglich" zu lösen. Der Punkt ist sehr interessant
> für mich.

Ja, das hiesse dann "functional design", aber dann mit einer
imperativen/OO-Sprache implementieren.

Ist durchaus nichts gegen zu sagen, ebenso, wie man
OO-Design auch mit ANSI-C implementieren kann.
Desser OO-Design mit ANSI-C implementieren, als
ohne Design sein und dann mit Frickel-Kacke auf die
Nase zu fallen (häufig/in vielen kleineren Firmen
anzutreffen, bes. sog. Startups (gibt's sowas noch?)
das einzige, was da richtig designt (/aufpoliert) ist,
sind die Unterlagen für die Geldgeber).


Auf der anderen Seite gibt es da immernoch das
"Plan To Throw Away" (Brooks).


[...]
> > > > Bin ja selbst relativer noch FPL-neuling, 
>  [...] 
> > 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.
> 
> Ja, dachte ich auch. Danach kann man aber diese Sachen auch
> brauchbar in z.B. Perl abbilden. Vielleicht sollten wir mal ein
> konkretes Problem probieren?

Gib mir noch etwas Zeit mit OCaml.
Ich mag keine halben Sachen. Wenn ich die Sprache beherrsche,
können wir das gerne mal machen. Im Moment erkunde ich noch
die schier unvorstellbar genialen Möglichkeiten. :)


> 
> > Mit anderen Worten: Das beste Vorgehen, mit der Sache weiter zu kommen
> > ist, daß Du Dir eine FPL installierst und es ausprobierst.
> 
> Na ja, dazu braucht man Zeit.

Die Installation ist recht einfach. ;-)
OK, das Lernen der Sprache braucht ein Weilchen. ;-)
(Ist immerhin reichlich unähnlich zu den typischen
anderen Sprachen...)

> Und erst am Ende kann ich erkennen,
> ob es mir was gebracht hat.

Wird auf jeden Fall was bringen.
Wie hatte der Master of The Bazaar mal geschrieben:
Lisp lernen erweitert den Horizont. Hier wird es nicht
anders sein. :)


> Ich werde in der Praxis sicherlich
> keine funktionale Sprache verwenden

Was ist "die Praxis"?
Nur berufliche Praxis, oder auch private?
(OK, ich kann verstehen, wenn Du nach einem langen Arbeitstag
nicht weiter kompilieren willst... ;-))

> (da ist in meiner Firma auch
> keine bei den zugelassenen Sprachen dabei). Aber Ideen kann man
> ja trozdem klauen :)

Na, wenns Deine Firma ist ;-) kannste das doch ändern. ;-)


> 
> > 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 geht nicht darum, daß das nicht verständlich war. Ich bin eben
> nur der Meinung, daß man es prozedural abbilden kann. Das mal
> also die Vorgehensweise eben auch in Perl verwenden könnte.

Naja, man kann es vermutlich ähnlich schlecht oder noch schlechter
Abbilden, als OO in ANSI-C.
Ob OO oder non-OO imperativ, man arbeitet mit Variablen
und Zuweisungen an Variablen, etc..
All das ist schon Arbeiten mit Seiteneffekten! In funktionaler
Programmierung geht das aber nicht.
Da gibt es nur name-value-bindings. Und ein solches kann man
nur einmalig machen. Macht weist man dem selben namen eine
Value zu, dann besteht die alte Value weiterhin, wird aber
von der neuen verdeckt und ist daher im scope nicht verfügbar.

Du kannst natürlich versuchen, alles weitgehend lokal
zu machen, also überall Blocks drum herum bauen, ...

Ein Beispiel, wo man z.B. Probleme mit Seiteneffekten
offensichtlich sieht, sind in C die && und ||
Konstrukte und wenn man in solchen Konstrukten
Funktinen aufruft, die eine Rückwirkung auf
die Auswertung dieses Konstrukts haben.
=> Abarbeitungsreihenfolge ist wichtig (in FP
ist die Reihenfolge der Abarbeitung egal,
denn eine mathematische Gleichung löst man auch
immer auf die selbe weise..., unabhängig davon,
wo man anfängt (z.B. Polynom bei höchster oder niedrigster
Potenz zuerst auszurechnen...)) 

Deshalb wird man ja vor solchen Konstrukten,
obwohl "das in C ja so wunderbar geht" in
aller Regel davon lieber die Hände lassen
(sonst ist's Scheitern vorgeplant!).

Aber das sind nur die offensichtlichen Probleme.
Andere Sachen sind dann eben globale Variablen
usw.



> 
> > 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).
> 
> Der prozedurale und der OO Ansatz sind schon sehr
> unterschiedlich. Beispielsweise hat "von außen gesehen" ein
> Objekt eben keine Daten - nur Methoden.

Der funktionale und der imperative/(prozedural/OO) Ansatz
sind eben noch verschiedener.
Im funktionalen Programmieren gibt's ja nichtmal sowas
wie Variablen (auch wenn man sie sich als nicht mit
FPL-Muttermilch aufgewachsener Imperativling manchmal so
noch bezeichne).

Schon eine Zuweisung, wie x = 5, oder Zugriff auf
Variablen über Referenzen ist nicht mehr FP.


> 
> > Bei FP geht das nicht: man bindet einmal einen Namen an eine
> > Value und damit ist der Fall gegessen. Man kann sie nicht ändern.
> 
> Das kann man in C++ sehr gut abbilden: man nimmt eine Referenz. Der
> kann (muß!) man einmal (bei der Erzeugung) einen Wert verpassen.

OK, ich erinnere mich da, ja, ja, da war was in C++.
Hmhhh.

> Die Referenz hat damit immer (zu ihrere Lebenszeit) den selben
> Wert.

Kann mit nur solchen Konstrukten in C++ programmieren?
Und falls ja, geht das auch ohne zu umständlich zu werden?


> 
> In C++ gibt es viele Fälle, wo Referenzen (man kann meist auch
> const pointer *const object verwenden, nur das gibt dann nur
> Warnungen) sehr angebracht sind. Es gibt aber auch Fälle, wo es
> mit Variablen einfacher geht.
> 
> > 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 ;-)).
> 
> Man kann die Seiteneffekte verhindern. Dazu muß man in C z.B. im
> Wesentlichen folgende Regeln beachten:
> 
> - keine globalen Variablen
> - keine static's in Funktionen

- keine Zuweisungen an Variablen
  (einigen wir uns auf einmalige Zuweisung, wie bei Referenzen,
   um dem Ziel nahe genug zu kommen.)



> 
> Dann kann man keine Seiteneffekte mehr produzieren.

Doch, s.o.


> Ich kenne
> übrigens bei schlechter Software viele Beispiele für unerwünschte
> Seiteneffekte; jedoch fallen mir keine bei guter Software ein
> (wenn ich mal an meine Praxis denke).

Jede Variablenzuweisung; Arbeiten auf Arraydaten z.B. fallen
darunter. :)


> 
> > 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.
> 
> Na ja, ich sage immer: "Die Disziplin muß vom Programmierer
> kommen.". Leider sind viele Programmierer nicht diszipiliert,
> also brauchen *diese* entsprechende Compiler :)

Ja, die Sprüche kenne ich (habe ich auch oft abgelassen;-)).
Ist ja auch richtig, daß die Disziplin vom Programmierer
kommen muß. Das bedeutet aber nicht, daß man deswegen
extra Sprachen nimmt, die einem das Leben schwer machen
(ja,ja, ich weiß, es gibt Leute, die springen an Gummiseilen
hängend von Brücken... warum nicht die Seile auch weg lassen?
*DANN ERST* ist der Kick ultimativ :-)) )


> 
> > [...]
> > > > 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.
> 
> Also eine reguläre Grammatik? Was macht man damit eigentlich so?
> Hast Du mal ein einfaches Beispiel? Heißt das, der Datentyp kann
> jeden konstruierbaren Wert erhalten, ja?

Mit den Teilen kann man Listen und Bäume konstruieren.
Also kann man damit auch Syntax-Trees abbilden.



[...] 
> > > 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).
> 
> yacc kann ja auch C code erzeugen. Sicherlich nicht so schön,
> aber geht. Braucht man Laufzeit-Variable Grammatiken? Mmmm...
> Hast Du ein Beispielproblem dafür?

Eine Sprache, in der man die Syntax umbauen kann?
Ein vernünftiges Literate Programming Tool, das mir
noch vorschwebt, braucht sowas vermutlich.
Macht (man in) TeX nicht auch so herbes Zeugs?
Im Prinzip kann man CGI-Scripte auch in TeX schreiben. ;)



[...]
> :) Ich weiß, was Du meinst. Aber "int" war gerade ein schlechtes
> Beispiel, denn:
> 
> myadd (x)
> {
> 	return x+3;
> }
> 
> müßte in C das gleiche sein (aber nur, weil int implizit
> angenommen wird). Aber sollte man nie machen, häßlich, sowas,
> finde ich.


Naja, ok, bezüglich kurzer Schreibweise und automatischem
Typen ermitteln, ist das richtig.
Was ich meinte, ist aber implizite Typ-Konvertierung.
Die Typen passen nicht zusammen, also würden Sprachen
mit strenger Typprüfung es nicht gestatten, diesen
Aufruf durchzuführen.
In manchen Sprachen hilft dann ein cast.
Und in wieder anderen muß man explizit eine Konvertier-
Funktion nehmen, oder eben eine Funktion nutzen, die 
mit dem Typ übereinstimmt (bzw. Parameter entsprechend
entgegennimmt).

Letzteres ist am klarsten, weil am explizitesten.



> 
> > und 36 als Rückgabewert von a() erhält, geht sowas eben nicht
> > in FPLs.
> 
> Na ja, es geht eben in beiden Sprachen.

Geht "nicht" in FPLs => falscher Typ!


> Gibt's denn was, was in
> Perl nicht geht? Ich meine, Perl kennt Listen...

Und man kann auch, wenn man keine Listen hat in C
welche Erzeugen. Man kann in C auch OO machen...
...es ist immer das selbe.
Solange eine programmiersprache allgemein genug ist,
um alles berechnbare zu berechnen (Informatiker faseln
dann gerne von Turingvollständigkeit), dann kann
man mit den Sprachen auch alles machen.
Also geht's auch in Assembler, oder TeX.
Oder mit nem Abakus ;-)



> Ich kann ja
> schreiben
> 
> sub filter ($@)
> {
> 	my $condition = shift;
> 	my $firstElem = shift;
> 	my @restList  = @_;
> 
> 	if (&$condition ($firstElem)) {
> 		return $firstElem, filter($condition, @restList);
> 	} else {
> 		return filter($condition, @restList);
> 	}
> 		
> }
> 
> Dann wird eine Liste returned, die alle Listenelemente enthält,
> auf die Condition true liefert (geht in Perl sicherlich
> einfacher, wollte nur die Definition, wenn ich sie denn noch
> richtig im Kopf habe, verwenden).

Im Prinzip geht das.
Du hast hier aber z.B. auch wieder keine Typprüfung.
Die must Du selbst einbauen, oder, wenn man es
anders wendet: Da Du hier keine Typprüfung eingebaut hast,
könnte man böswillig sagen, die Disziplin des Programmierers
läßt hier zu wünschen übrig.

Schon klar, daß das ein Beispiel ist, bei dem es darum geht,
abzuchecken, wie man mit nicht FPLs FPL-ähnlich arbeiten
kann (z.B. weil's da Vorgaben der Programmiersprachen
vom Cheffe gibt (ich würde das nicht lange mitmachen)).

Aber eben da ist dann der Haken: Bei der Prüfung der Argumente
- und diese kann erheblich aufwendig werden, wenn man
es richtig machen will - muß man eben wieder selbst
Arbeit rein stecken.


Und selbst, wenn Du prüfst: Es bleibt das Problem, daß
man die Daten immer nur als scalar bekommt - auch bei
Referenzen -, und wenn die Daten "gefaket" sind
 - z.B. wollte man Referenzen mit regexps ändern, weil
man "so coole features" nutzen wollte, und dabei hat
man einen Fehler gemacht -, dann hast Du das Prinzipielle
Problem, daß Perl Dir nichtsicher stellt, sowas tatsächlich
auch zu erkennen. Wenn Du eine falsche Referenz übergibst,
gibt's halt noch ne warning/Perl bricht ab.
Aber wenn da "die tollen Features" (als Notbehelf wegen
Unzulänglichkeiten der Sprache) Dir eine falsche
Referenz übergeben, merkst Du es vielleicht erst zu spät.
(Mit etwas Glück noch 1 Tag vor Auslieferung an den Kunden;
 "Gute Nacht"...=> Gute Nachtschicht").


Was zum Beispiel, wenn Du print als test (condition)
übergibst? Mit Typprüfung wäre sowas aufgefallen.
So hast Du nun immer true. 





> 
> Also:
> 
> @list = (1, 2, 3, 4);
> 
> $isEvenCond = sub { $p = shift; return (int($p/2) == ($p/2)); }
> 
> @list2 = filter ($isEvenCond, @list);
> 
> list2 ist dann (2,4) (untested).
> 
> sub filter muß ich nur einmal bauen (geht bestimmt auch
> eleganter, aber egal).

Geht auf jedenfall safer.


> 
> Ist doch schon in Richtung funktionales Vorgehen, oder?

Zumindest nicht völlig in die andere Richtung.
Halt mit allen Einschränkungen und so... ist das
ein Ansatz.

Du hast aber noch vergessen, die Ende-Bedingung
einzubauen: Wenn die Liste abgearbeitet ist,
musste aufhören....


Das ist natürlich alles nur eine Notlösung.
wie Perl mit all zu tiefen Rekursionen umgeht,
weiß ich auc nicht. FPLs sind auf Rekursionen
spezialisiert/optimiert.


[...]
> > > 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.)
> 
> Rapid Prototyping ist manchmal ganz brauchbar, finde ich. Aber
> hier muß man auch wieder vorher wissen, in welcher Sprache man
> arbeiten möchte. Meintest Du das?

Ich meinte, wenn man's eh in Perl schreiben kann, weil's
schnell genug ist, dann sollte man Perl statt C nehmen,
denn man wird damit schneller fertig.
Ist Perl dann doch zu langsam, weiß man das wenigstens
recht schnell (evtl. reicht#s mit Optimierung doch noch).

Wenn man aber C nimmt und ewig braucht, wird man - von
der längeren Implementierungsdauer  mal abgesehen - auch
nicht erfahren, ob's in Perl nicht doch schnell genügend
laufen würde und wieviel schneller man mit der Arbeit
fertig ist.

Das selbe gilt dann auch für die eventuell aufgedeckten
Design-Schwächen/-Fehler. Die findet man natürlich
schneller, wenn man seinen Code schneller fertig gestellt
hat.

Deswegen ist's vielleicht sogar dann sinnvoll, etwas in
Perl statt C zu entwickeln, wenn man weiß, das Perl für
die Anwendung definitiv zu langsam ist (von zeitkritischen
Aufgaben natürlich abgesehen).


Was hier für das Verhältnis Perl<->C gesagt wurde, gilt natürlich
auch für andere Sprachen.

[...]
> >  (Da gibt's nen Aufsatz von Stroustroup zu dem Thema, dem
> >   Tcl-Entwickler/Erfinder, der das gut erklärt.)
> 
> Hat der nicht C++ erfunden? TCL ist doch von Ousterhoust? Aber
> egal.

Ja, stimmt, wie konnt' ich die beiden nur verwechseln?

Naja, ist ja alles imperatif. :)


> 
> > > Perl also für die Helferchens und so.
> > 
> > Naja, man kann auch schon Applikationen damit bauen.
> 
> Wieviele TOCs ungefährt? Mehr als 1000?

TOC?
Oder LOC?

Kommt immer drauf an....

Wie groß das Projekt damals war, weiß ich nicht mehr.
Muesste ich mir mal alles aufschreiben.
Jedenfalls war das schon was feines. Testsoftware für
Mail-durchs-Internet-und-durch-die-Verschluesselungsgeräte-
Tests.
Mit Postscript/pdf-Dokumentations-Modul für die Tests. :)


> 
> > > Externe Sachen (CGI Interfaces)
> > > kann man ganz gut in Perl machen (hab ich auch), aber innerhalb
> > 
> > Ja. Entweder direkt, oder CGI.pm. 
> 
> CGI ist schon richtig, aber egal.

CGI.pm ist auch richtig, aber egal.


 
[...]
> > Um die Seiteneffekte kommt man nicht umhin.
> > errno ist nervig, wenn man mit plain C arbietet.
> 
> Muß man ja nicht machen. errno ergibt sich eben aus dem
> libc/kernel Zusammenspiel. Na ja, die Idee gibt's öfter, nennt
> sich auch oft lastError oder so. Hat auch Vorteile :)

Gegen errno an sich ist nichts zu sagen.
Aber wenn man's bequemer kriegen kann... au weia,
ich werde alt und lasse mir plötzlich wie ein alter
Pascha gerne von meinen Programmiersprachen die
Latschen ans Sofa bringen.
Was waren das noch für Abenteuer, mit DATA-Zeilen
von Basic aus die Assemblercodes für den C64 ins
RAM zu poken und dann dort hin zu springen... :)

Exceptions - die nicht vorhergesehenen ;-) - und man
konnte wieder mal den Ausschalter drücken. ;-)
Immerhin hat das booten nicht so langegedauert. :)
Aber die Datassette war so lahmarschig....


[...]
> > 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.
> 
> In C++ schmeiße ich da einfach immer ne Exception. Macht sich
> ganz gut. Nicht so westenlich, *wie* man nun den
> Fehlercode/Meldung kriegt/erzeugt. 

Naja, so geht das dann in Ocaml auch. Da macht man auch mit
Exceptions rum.


[...]
> > Was dort aber drinsteht sollte korrekt sein => also eben
> > doch implementationsabhängig, wie const gehandhabt wird
> 
> Ja, leider.
> 
> > (Also eben doch auf Sand gebaut; const kann, muß aber nicht
> > hilfreich sein, eben wegen der Implementationsabhängigkeit
> 
> Na ja, stimmt, aber muß man eben einen guten Compiler nehmen.
> Aber Du hast Recht, wenn man es ganz genau nimmt, gibt es nicht
> ein C, sondern hunderte C-Sprachen. Die C-Sprachfamilie :)

Aber nur ein ANSI-C.


[...]
> > 2.: Schon mal den eigenen Code nach 1/2 oder 1 Jahr wieder
> >     ausgebuddelt und angeschaut?
> 
> klar, geht prima. Ich kommentiere ja :) Meistens... :)

Oh, ein eher seltenes Exemplar. ;-)



[...]
> Ja, ich sage manchmal: Code soll nicht nach Größe oder
> Geschwindigkeit, sondern nach Lesbarkeit optimiert werden.

Guter Ansatz.


[...]
> > Welcher MUA?
> > (Neugier!)
> 
> Na, ich verwende mit Begeisterung "mutt", der alles übertrifft,

wat mutt, dat mutt? ;-)


> was ich sonst so kenne, wenn man viel Mail schreibt. Aber muß man
> dafür erst ziemlich konfigurieren, damit er bunt wird etc.

Also, Bunt ist mir nicht so wichtig.
Aber struktur der Anzeige.
Wenn ich einen newstgread habe, willich, das der aufgegliefdert
dargestellt wird (Baumstruktur).
Wenn das ein Mailer auch bietet, hat er gute Chancen, mit mir
einen neuen Nutzer zu gewinnen.


[...]
> Alles nicht so schick wie ein lokaler call. Wir haben da viel
> experimentiert, JNI, CORBA, TCP und sowas. Letzlich haben wir
> dann doch vieles zweisprachig gebaut. TCP ist zu einfach, um
> Objekte zu übertragen (muß man ja händisch serialisieren und so),
> und bei CORBA kann man eben schlecht die Schnittstelle ändern.

Übertragen von Objekten über's Netz?
In Objective-C/cocoa-Environment rufst Du da nur die
entsprechende Methode auf und bekommst die Objekte
ausgedumpt.
Tja, Apple halt, was soll man von denen anderes erwarten?
Sagen nicht viel, aber machen ganz feine Sachen. :)




> Also haben wir eine flexible CORBA Schnittstelle und davor
> Wrapperklassen (genauer: Adapter und Dekoratoren) gebaut, damit
> man es komfortabel benutzen kann. Ist echt nicht einfach, wenn
> man Schnittstellen braucht, die "abwärtskompatibel" sein sollen.
> Aber das hängt immer stark von den Anforderungen ab.

Naja, so kompliziert kann das doch auch nicht sein. ;-)
Verschiedene Schnittstellen nicht OO-mäßig, sondern
über unterschiedliche Syntaxen zu verkoppeln,
die dann halt ineinander übersetzt werden müssen,
das wäre eina nderer Ansatz; einer, der den FPLs
entspräche, und einer, der vermutlich letztlich
einfacher zu realisieren sein wird.

(Klar, an den Punkt muß man auch erst mal kommen...
 aber Syntaxen scheinen doch eher handhabbar als
 Objekthierarchien, oder was meinst Du?)

 
[...]
> > > > Die haben mir gleich alle 4 Weisheitszähne gezogen.
> > > 
> > > Na huch, und auf welcher Seite kaust Du nu?!
> > 
> > Vorne rechts. Da ist's ok. ;-)
> 
> Na, wär' nix für mich... Ist das gut verlaufen? Ich meine, ohne
> Gaumenraumdurchbruch und sowas?

Was? Klingt ja schlimm.
Ne, habe auf der linken Seite unten ne Schwellung.
Aber ich habe noch andere leute in Erinnerung,
da sah das schlimmer aus.

> Bei mir gab's irgendsowas. Frag
> mich nicht warum, aber ich hatte ein blaues Auge davon
> (ungelogen! Es war blau, als hätte ich mich gekloppt!). Nervig
> war das.

KRASS!

Da hast Du zu dem Spruch "jemandem auf den Zahn fühlen"
wahrscheinlich ein etwas anderes Verhältnis, als vorher, was?


Ciao,
   Oliver