[linux-l] LinuxScript?

[Steffen Dettmer]

* 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
> > man auch in Perl schön. new ist genau das, was Constructor in C
> [...]
> 
> Namespace in C?
> 
> OK, ich geb's zu, ich habe mir Dein Beispiel nur flüchtig angeschaut. :)
> Aber Namespaces in C? Na hör mal. ;-)

Das ist doch völlig unerheblich, ob ANSI C die Syntax nu kann
oder ob es dann C++ ohne OO ist.

Ich schrieb schließlich:

> > > > In C++ (ohne OO) kann man das Directory-Headerfile in einem
> > > > 
> > > > /* typedef struct Directory {...} mit Funktionszeigern*/
> > > > namespace Directory

Nicht C. Nur der Vollständigkeithalber. Es spielt wirklich keine
Rolle.

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

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

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

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

> > Weil es C++ gibt.
> 
> Lohnt sich der Lernaufwand nicht. :)

Immer diese unbegründeten Aussagen...

 [...] 
> In dem Buch dazu steht uch ein bische was zum OO
> als Vergleich Ocaml vs. Java.

Und was denn nun?

> > > Nein. Nur weil Du das weglässt, ist Deine Programmierung
> > > noch nicht funktional.
> > > Schon globale Variablen schmeissen alles über den Haufen.
> > 
> > Die wollte ich doch weglassen :)
> 
> Na und?
> Das Wesentliche fehlt aber dennoch.

Was denn nun? Sag schon!

> > > Und wie schaut's mit Funktionen als Parameter und
> > > Rückgabewerten aus?
> > > Geht nicht. In C muß man mit Pointern rum frickeln.
> > 
> > Geht also doch. Ist sicher nicht ideal. Geht in Perl sicher
> > besser. Aber geht es nun ode rgar nicht?
> 
> Geht nicht.

OK, Aussage erkannt. Begründung nicht gefunden...

> Oder machst Du OO in ANSI-C?

Was hast denn das jetzt mit Funktionen als Argument zu tun?!

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

Wie sind die Standard-Operatoren zwischen Zahlen und
Listen/Mengen definiert? Was ist denn nun [1,3] < [2] ?

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

> 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? Es macht schon
Sinn. Gerade, wenn man näher am System arbeitet.

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

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.

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

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

> Kein Vergleich.

Begründung vermißt.

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

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

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

> Wie machst Du das, wenn Du eine BNF hast in C++ oder Perl
> oder Java?

Einen regulären Ausdruck anwenden?

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

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

> > Wo ist da nun der Hammer?! Geht doch so in Perl auch ziemlich
> > ähnlich?!
> 
> Nein.

Und *WO* ist denn nun der Hammer? Bitte begründen.

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

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

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

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

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

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

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

> > > 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 (die ungereaden einmal, die gerade zweimal
"anfassen"), dann die neue Liste durchgehen (nochmal die geraden
"anfassen"). Macht man das iterativ, muß man jedes Element nur
einmal anfassen.

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

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

> => Frickel.

Warum? Begründung fehlt.

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

> > > Diese Möglichkeit ist echt wat feinet. :)
> > 
> > Ja, erinnert mich sehr an Perl.
> 
> Ist'a aber nicht.

Context verloren, sorry.

> [...]
> > > 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
etliches nicht verstanden, schließlich stecken in Java sehr viele
gute Ideen, Erfahrungen und Konzepte.

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

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

oki,

Steffen

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