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

[Steffen Dettmer]

* 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]
> 
> Sorry, für Deinen Aufwand.
> Ich fand den vielen Code zu viel Code.

Na ja, Du solltest es ja nachvollziehen können. Na, egal, fasse
mich kürzer.

> AppleScript gefagt, wenn es ihn schon gäbe),

:) An *dem* Thema sind wir lange vorbei :)

> [gegenseitige Anpissrei gelöscht]

Gute Idee, ist das geklärt :)

> > 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?

> 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 :)).

> > 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.

> > ["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.

[...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...

> 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.

> > > Du willst Dein Argument stützen, indem Du ein Gegenbeispiel
> > > widerlegst?
> > 
> > Ja, genau.
> 
> Tja, normalerweise kann man Theorien nicht beweisen,
> sondern sie nur widerlegen...

Aber Begründungen kann man widerlegen. Na, egal :)

> Gegenarguments ist die Theorie aber nicht bewiesen,
> sondern nur das Gegenargument abgeschmettert.
> => Kommt halt das nächste...

Ja, das ist doch schön. Letzlich bleiben ein paar Argumente
übrig, die der Wahrheit vermutlich recht nahe kommen.

> ...aber lassen wir das. ;-)

Ja, besser ist das :)

> 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 ;)

> Stringtext, und letztlich sind auch Listen aus Scalaren
> aufgebaut und Hashes sind halt verkettete Scalare, Referenzen
> sind auch Scalare.

Genau: es gibt Skalare, Listen und Hashes. Skalare kann man bei
Bedarf weiter unterscheiden. 

>  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...

> 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?

> 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.

> in anderen Modulen in den Namespace eindringen,

Perl's Philosophie. Da man das weiß, ist's ok. Aber natürlich
würden sich bei Großprojekten sicherlich Probleme dadurch
ergeben. Aber mit Perl kommt man wirklich erstaunlich weit.

> > 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. Das kann man weniger weit (Perl) oder ziemlich
weit (Ada) treiben. Hat alles Vor- und Nachteile. Vereinfacht:
bei ersterem kürzere Entwicklungszeit, bei zweiterem geringere
Laufzeitfehlerwahrscheinlichkeit. Je nach Problem überwiegt das
eine oder andere. Man darf jetzt aber nicht sagen, Perl wäre
besser als Ada oder umgekehrt. Raumfähren programmiert man eben
in Ada, und CGI Scripte in Perl.

> [...]
> > > Tja, vermisst Du nichts?
> > 
> > Doch, aber an ganz anderen Punkten.
> 
> An welchen Punkten denn?

Zum Beispiel das C++ keine Interfaces kennt, daß man Header nicht
kompilieren kann, und das man privates aus Klassen in den Header
schreiben muß, das const violations nur Warnings sind usw.

> > 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. Wenn ich eine GUI in C bauen soll, weiß
ich aus Erfahrung, daß das umständlich wird, und nehme lieber
Java. Wenn ich in Java einen Daemon programmieren möchte, weiß
ich, das gibt diverse Nachteile, und nehme lieber C++. Überhaupt
nehme ich immer lieber C++ als C, aber C++ gibt's nicht für
alles, dito Java etc. Erst nachdem das Design fertig ist, kann
man sich für ne Sprache entscheiden. Natürlich kommen da noch
weitere Faktoren dazu: welche Libs für welche Sprache sind
verfügbar, was ist mit Performance, Stabilität,
Programiererfahrung etc.

 [...] 
> 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. 

> > 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."

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

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.

> [...]
> > > 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?

> 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. Und erst am Ende kann ich erkennen,
ob es mir was gebracht hat. Ich werde in der Praxis sicherlich
keine funktionale Sprache verwenden (da ist in meiner Firma auch
keine bei den zugelassenen Sprachen dabei). Aber Ideen kann man
ja trozdem klauen :)

> 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.

> 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.

> 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.
Die Referenz hat damit immer (zu ihrere Lebenszeit) den selben
Wert.

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

Dann kann man keine Seiteneffekte mehr produzieren. 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).

> 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 :)

> [...]
> > > 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?

[...abstrakte Klasse...]
> > > > > Wie soll man sowas in C++/Perl machen?
 [...] 
> > > Aha. Klingt aufwendig.
> > 
> > Ist es aber nicht. Man schreibt lediglich "= 0" dahinter. 
 [...] 
> 
> (kurzes!) Beispiel möglich?

Klar:

class SomeAbstractClass
{
	public void func (void) = 0;
}

Wenn man dann schreiben möchte: 
SomeAbstractClass s;
gibt es einen Fehler, weil s ist abstrakt wegen "func". Beispiel
2:

class Cat
{
	public int getSpeed(void) = 0;
}

class SlowCat : public Cat
{
	public int getSpeed(void)
	{
		return 5;
	}
}

class FastCat : public Cat
{
	public int getSpeed(void)
	{
		return 10;
	}
}

Dann:

//Cat c; //falsch
SlowCat slow;  //ok
Cat &c = slow; //ok, referenz auf ne *lahme* Katze
assert( c.getSpeed() == 5); //ist wahr, weil lahm.

Das heißt also, jede nicht-abstrakte Klasse *muß* getSpeed
implementieren, sonst ist sie eben doch abstrakt.

> > 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?

> let myadd3 x =  x + 3;;
> 
> das ist kürzer als in C:

Ich hatte mit "länger" nie ein Problem, auch nicht bei
Programmiersprachen. Auch Pascal ist ok, da muß man noch function
dazuschreiben. Ist aber ok. Schreibt man ja nur einmal je
Funktion.

> 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.

:) 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.

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

Na ja, es geht eben in beiden Sprachen. Gibt's denn was, was in
Perl nicht geht? Ich meine, Perl kennt Listen... 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).

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).

Ist doch schon in Richtung funktionales Vorgehen, oder?

> > 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?

> > Ü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?

Nein. Java ist zwar nicht so schnell und für Maschinennahe
Anwendung weniger geeignet, aber irgentwie schöner. Dafür hat C
weniger Probleme mit JDK Bugs :) Na ja, hat alles so seine Vor-
und Nachteile. Und wenn man ein Programm um eine komplexe C++ Lib
strickt, wird es in Java schweirig. Muß man dann mixen, wenn man
Java für was anderes braucht / möchte. So einen Fall haben wir
eben, na ja, was hilfts :)

> 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.

Ja, die Java/C++ Programme 

>  (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.

> > Perl also für die Helferchens und so.
> 
> Naja, man kann auch schon Applikationen damit bauen.

Wieviele TOCs ungefährt? Mehr als 1000?

> > 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.

> => Apache: modperl ist fein :)

Ich verwende das nicht. Möchte nicht alle CGI's im selben Prozeß
haben.

> > einer Anwendung (GUI oder Server) geht das nicht wirklich schön.
> 
> Im Apache als modperl ist's aber recht flott.

Na ja, aber eben nicht mal ein eigener Prozeß. Nee, mag ich eben
nicht. Möchte es lieber sauber und mit SuExec.

> [...] 
> > > 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.

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 :)

> 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. 

> Daß alle Leute schlechte Vererbungshierarchien benutzen, sei
> mit obigem nicht gesagt. Aber meist wird zuviel vererbt und zuwenig
> aggregiert.

Ach, ich weiß nicht. Gibt doch für Vieles gute Design Patterns.
Ich habe nicht den Eindruck, daß zuwenig aggregiert wird.

> > > [...]
> > > > > 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". '

Es spielt doch eigentlich keine Rolle, wie der "Ausführer" das
Programm nun abarbeitet. Hat auch alles vor- und Nachteile. Java
geht hier eben ein Mittelweg, der ist dann ein Mittel-Ding :)

[C 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.

Ja, gibt ja ANSI C usw.

> 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 :)

> Habe gestern mal die (nicht-Tk) graphics-Lib (Ocaml-Standardlib)
> ausprobiert.

Na gut, wenn es sowas gibt, kann man da was bauen. Bei Java ist
da schon viel vorhanden, was auch ganz gut ist (Swing z.B.).
Müßte man gucken, ob und wie man da mit z.B. Ocaml weiterkommt...

> > Na ja, egal, weiß eh nicht, was Du damit sagen willst.
> 
> @@@@@@
> 
> Ist der Verständlich? ;-)

:) Nicht wirklich...

> 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.

oki.

> 2.: Schon mal den eigenen Code nach 1/2 oder 1 Jahr wieder
>     ausgebuddelt und angeschaut?

klar, geht prima. Ich kommentiere ja :) Meistens... :)

> 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. ;-)

Yep, da hsat Du Recht. Ist aber vermutlich in allen Sprachen
so...

> > Sicher? Glaube ich nicht, ist doch extrem rechenaufwendig.
> 
> a) Schnell vorliegen, weil man nicht ewig implementiert

Na ja, meistens läuft ja Programm ja mehrfach. Kommt natürlich
wieder darauf an. Wenn man eine bestimmte mathematische Aufgabe
lösen möchte, und C nimmt, macht man schon was falsch, klar.

> b) auch schnell, weil die Verarbeitung schnell genug ist

Wenn man es hunderttausendmal braucht, und das schnell und auf
einer embedded Plattform, muß man aber dennoch vermutlich C
nehmen...

> 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)

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

> > Mein MUA macht das so, wie Du es von News gewohnt bist, just BTW.
> 
> Welcher MUA?
> (Neugier!)

Na, ich verwende mit Begeisterung "mutt", der alles übertrifft,
was ich sonst so kenne, wenn man viel Mail schreibt. Aber muß man
dafür erst ziemlich konfigurieren, damit er bunt wird etc.

> > 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. ;-)

Ja, bestimmt, die machen das Leben aber nicht unbedingt
einfacher.

> Notfalls fork/exec?
> Ok, Sockets...

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.
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.

> -> 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. :)

C (und natürlich handoptimiertes Assembler) ist im Speed nie zu
schlagen, klar. Sieht man gut bei Ada: Der Compiler muß soviel
extra-Code generieren, um Prüfungen zu machen etc., das es
langsam werden muß. Ist eben ein Zielkonflikt zwischen Sicherheit
und Speed.

> > > 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? 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.

> [...]
> > > 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. ;-)

Na ja, solange es *Dir* wehtut :) SCNR.

oki,

Steffen

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