[linux-l] LinuxScript?
Oliver Bandel
oliver at first.in-berlin.de
Mo Apr 1 19:55:17 CEST 2002
Moin,
On Mon, 1 Apr 2002, Steffen Dettmer wrote:
> * Oliver Bandel wrote on Mon, Apr 01, 2002 at 14:29 +0200:
> > On Sun, 31 Mar 2002, Steffen Dettmer wrote:
> > > * Oliver Bandel wrote on Sun, Mar 31, 2002 at 21:29 +0200:
> > > Da die Eigenschaften sehr ähnlich sind, würde man hier jedoch nur
> > > eine ziemlich flache Vererbungshierachie hinkriegen, kann mir
> > > nicht vorstellen, daß sowas sehr viel bringt.
> >
> > Vererbung ist zwar das, was alle immer gleich mit OO verbinden.
>
> Ja, Benutzerdefinierter Datentyp, Vererbung und Polymorphie sind
> doch die Kriterien für Objektorientierung. IIRC. Achso, und
> natürlich Datenkapselung bzw.
> Interface-Implementierungs-Trennung, Geheimnisprinzip oder wie
> auch immer man diese Kapselung/Schichtung/Trennung nennt.
>
> > Zu OO gehört mehr als nur Vererbung, leider wird immer, wenn
> > man OO anführt, auch quasi reflexartig an Vererbung gedacht.
>
> Ja, ohne Vererbung keine Polymorphie. Ohne Vererbung und
> Polymorphie bleibt nur Benutzerdefinierter Datentyp. Das ist ja
> auch z.B. ein struct. Und dieser sicherlich nicht
> objektorientiert :)
>
> > Aggregation etc. ist aber oftmals sinnvoller als Vererbungs-Fanatismus,
>
> Na ja, kommt auf das Problem an. Ein "ist-ein" schreit nach
> Vererbung, ein "hat-ein" schreit nach Aggregation...
Aber wer auf "OO" immer nur "Vererbung" antwortet,
ist vermutlich schon zu sehr eingenebelt.
Da bin ich jedenfalls erst mal skeptisch.
Wenn ich aber - um mal wieder zurück zu kommen -
das eine Script, das ich mal beispielsweise hier gemailt hatte,
mir nochmal anschaue, finde ich das von der Syntax her schnuckelig.
Das geht ganz ohne krüppelige C++-Syntax, daß man da ein File
nach seinen Permissions fragt.
>
> > > Natürlich kann man sockets von files ableiten und die
> > > Socket-Eigenschaften hinzufügen. Aber in der Praxis braucht man
> > > sowas eher selten.
> >
> > Tja, man sollte eben nicht immer gleich alles voneinander
> > ableiten/vererben wollen... :)
>
> Hier ist das ja richtig, denn ein Socket ist ein File. Kann nur
> bißchen was spezielles mehr. Und ein TCP oder UDP Socket ist ein
> Socket, kann nur wieder ein bißchen mehr. Paßt schon. Macht nur
[...]
Ja, ja. Mein Ausgangspunkt war ja der von Directory und File.
Deswegen hatte ich das jetzt noch im Hinterkopf.
[...]
> > > Na ja, ich gebe jedoch zu, sogar selbst sowas
> > > schon gebaut zu haben :)
> >
> > So, so... ;-)
>
> Aber wie angedeutet, daß ist dann in meinen Augen eine höhere
> Schicht als "OS". Natürlich könnte man sowas in die
> Standardbibliotheken oder theoretisch noch tiefer ins System
> integrieren.
Es gibt Leute, die würden das befürworten.
[...]
> Kommt vielleicht noch. Java hat ja damit ganz gut
> angefagen - hier gibt's sehr umfangreiche Bibliotheken. Das hat
> schon so seine Vorteile.
Kaffee ist zum Trinken da, nicht zum Programmieren.
> > > > Ebenso könnte man auch das Objekt Prozess nach dem pwd/cwd (getcwd()),
> > > > seiner ID, etc. befragen.
> > >
> > > Sicherlich die Instanz eines Prozesses. Aber macht erst wirklich
> > > Sinn, wenn es dann "Kinder" gibt, die spezielle Eigenschaften
> > > haben, die jedoch nicht immer interessieren, so daß man
> > > beispielsweise Polymorphie ausnutzen könnte...
> >
> > Wie meinen?
>
> Na ja, wenn man 100 Instanzen von Prozessen nach irgentwas
> handhabt, funktioniert das auch mit nicht-objektorientierten
> Datentypen - also z.B. structs - ganz prima. Die kann man dann
> auch in ein Modul packen. Dann hat man einen prima
> benutzerdefinierten Datentyp (mit Kapselung), ganz ohne OO, und
> das würde prima funktionieren. Würde ich vermutlich lieber in C++
> bauen (wegen der Luxus-Syntax und strengen Typprüfung), und hier
> vermutlich ne Klasse definieren. Aber das ist ja dann nicht
> wirklich objektorientiert, weil man eben die Merkmale der
> Objektorientierung überhaupt nicht wiederfindet. Es sieht zwar
> vielleicht so aus, weil da "class" steht, aber ohne Vererbung und
> Polymorphie ist es eben *nicht* OO.
Ich weiß immer noch nicht, auf was Du da hinaus wolltest.
Irgendwas mit den Eigenschaften des Prozesses.
>
> > > Eigenschaften zu haben, ist kein hinreichendes Kriterium für
> > > Objekt/Klassenkandidaten, finde ich.
> >
> > Sage ja garnicht, daß das hinreichend ist.
> > Finde es dennoch schnuckelig, wenn ich das Directory
> > fragen kann, wieviele Files es hat, oder wenn ich
> > die Files fragen kann, ob sie schreibgeschützt sind...
>
> Kannst Du doch auch ohne OO. In C würde ich sowas machen:
[...]
Klar geht das ohne OO.
[...]
>
> /* Headerfile */
> int getDirectoryFiles(void);
>
> /* C File */
> /* typedef struct Directory {...} */
> static Directory dir_;
>
> int getDirectoryFiles(void)
> {
> return dir_.fileCount;
Häh?
Wie kommt das da rein?
> }
>
> static void somePrivateMethod(void)
> {
> //cannot be called from outside
> }
Sieht übrigens nicht nach ANSI-C aus.
>
>
> Ich hab einen benutzerdefinierten Datentyp, Geheimnisprinzip
> (schließlich kommt man nicht direkt an dir_ ran, gibt nur ein
> paar "getter" und andere Methoden; gibt auch ne Unterscheidung
> zwischen "public" und "private" Methoden). Man kann dann das
> Directory fragen, wieviele Files es hat.
Du fragst das Directory natürlich nicht, sondern Du setzt
eine Funktion an, um den Wert zu ermitteln....
> Zusätzlich kann man
> natürlich statt einem einzigen "static Directory dir_;" auch ne
wat'n für'n "dir_" ?
[...]
> /* C File */
> Directory *new(void)
> {
> Directory *this = malloc (sizeof(Directory));
> this->memberValue = "inital values...";
> return (this);
> }
Ach sowas hast Du vor...
Naja, das Teil würde ich lieber new_directory nennen,
sonst fälltst Du da evtl. auf die Nase, wenn Du denkst,
das wäre ein allgemeines new. :)
[...]
> Dann kann man schreiben:
> Directory *dir = newDirectory();
> getDirectoryFiles(dir);
>
> Man kann auch noch Funktionspointer in den Struct miteinbauen,
> dann kann man schreiben:
>
> int count = dir->getFiles();
>
> Alles C. Sieht zwar schon für manche nach OO aus, ist es aber
> nicht.
Ist aber OO-stil, oder eben OO-ähnlich.
OK, man kann auch noch mehr Zeugs dazu implementieren
und echtes OO zusammen bauen.
Aber dann kann man lieber gleich ObjectiveC nehmen.
Und dadrauf aufbauend dann eine Scriptsprache schreibend könnte
man z.B. eben zu jenem AppleScript gelangen (oder LinuxScript?).
[...]
> Sieht doch wirklich schon sehr nach OO aus - ist es aber trozdem
> nicht. Und so wird es ja in C auch oft gemacht. Vielleicht nicht
> mit Funktionszeigern, aber es wird gemacht.
Mit Funktionszeigern usw. kommt man dann aber erst in die
interessanteren Regionen. :-)
So, jetzt mehren wir uns aber doch ganz schön aus...
[...]
> > Ich sage ja nicht, daß man das gesamte drunter liegende System
> > neu schreiben soll. Eine weitere Schicht/Sprache/Scriptingmöglichkeit
> > wäre aber was feines.
>
> Gibt's doch: Perl Modules, ACE, Java,... Die machen ja im Prinzip
> nix anderes; nur das nur Perl eine Scriptsprache ist.
Aber Du hastr den entscheidenden unterschied in der
Syntax nicht gesehen.
Perl-Programmierung ist größtenteils prozedural; man
kann auch OO etwas beimengen.
Richtig schnuckelig wirds aber erst mit funktionaler
programmierung; da ist mit Perl Schicht.
(Evtl. in Perl 6?)
>
> > Also nicht alles umkrempeln, sondern was oben drauf stülpen.
>
> Ja, sowieso, klar.
Na, gut.
>
> > > Eigenschaften kann man auch
> > > sehr gut über klassische Datentypen handhaben, also ein C-Struct,
> > > dessen Instanz in einem Modul lebt. Natürlich ist sowas technisch
> > > gesehen ziemlich genau eine Klasse. Ich meine ja nur, es gibt
> > > hier nicht unbedingt notwendigerweise einen Bedarf.
> >
> > Meine ich ja auch nicht, daß es Bedarf gibt...
> > aber vielleicht Bedürfnis? ;-)
>
> Na ja, ich weiß nicht, warum? Es geht ja genau so in z.B. Perl,
> nur das eben die Syntax anders ist.
Nein. Ich kenne Perl recht gut. Letztlich ist es ein enhanced C
plus etwas OO.
> Im Prinzip das gleiche.
Ja, Perl und C sind im Prinzip das Gleiche.
Das ist es ja, was ich meine...
Letztlich ist auch C und C++ sehr ähnlich.
Das bischen OO macht den Kohl nur unbedeutend fetter.
[...]
> > Also, zumindest wenn man nicht immer wieder das Rad in C neu
> > erfinden will, also eher high-level programming machen will,
> > bietet sich eine ergänzende Schicht an.
>
> Na, warum denn C in Unix?
Warum nicht?
> C ist doch so umständlich, unflexibel
> und typunsicher.
In Deiner Mail (oben? unten?) meintest Du bzgl. C,
daß das mit dem SIGSEGV doch auch mittels
Handlern handlebar ist.
Naja, klar, Hadler einbauen und mit setjmp/longjmp
rumpopeln.
Ist auch alles ok. Aber ist nicht, weshalb ich diesen
Thread hier startete. Soll ja gerade nicht Unterholz-Programmierung
werden....
> Da kann man meistens C++ nehmen, gibt's ja für
> Unix :).
Warum denn C++?
Ist ja umständlich, unflexibel, ...
Wenn schon ein C mit OO, dann lieber Objective-C.
Aber letztlich ist das kein vergleich zu den
anderen von mir bereits mehrfach erwähnten Scmankerl-Sprachen.
> Und für C++ gibt's ja dann ACE usw.
ACE?
Was'n das?
Wieder irgend wo ein Hype-Zeugs, das im nächsten Jahr
wieder vergessen ist - und viele Firmenpleiten begleitet
(eingeleitet?) hat? :->
[...]
> > Ich meine wirklich funktional.
> >
> > Prozedural ist's, was man in C macht. Funktional ist's, wie
> > man in Scheme/Haskell/... macht.
> > OCaml btw. ist prozedural, funktional und OO. Wird Zeit, daß
> > O'Reilly endlich mal die englische Fassung des Ocaml-Buches
> > herausgibt.
>
> Jetzt hab ich sicherheitshalber selbst mal nachgegeuckt. Hab z.B.
> folgendes gefunden:
>
> 1. Alle Programme und Prozeduren sind Funktionen, die eine klare
> Unterscheidung zwischen Eingabegrößen (Parameter) und
> Ausgabegrößen (Resultate) vornehmen.
>
> 2. Es gibt keine Variablen oder allgemeine Zuweisungen. Variable
> werden mittels Parameter realisiert.
>
> 3. Es gibt keine Schleifen. Zyklische Abläufe werden durch rekursive
> Aufrufe realisiert.
>
> 4. Der Wert einer Funktion hängt nur vom Parameterwert ab und nicht
> von der Verlaufsform innerhalb der Funktion (referentielle
> Transparenz).
>
> 5. Funktionen stellen selbst Werte dar (als sogenannte first-class
> values). Es gilt das Substitutionsprinzip.
[...]
Naja, manches scheint da etwas rigide ausgedrückt zu sein.
Die meisten Sprachen gestatten sehr wohl iterative Programmierung,
Schleifen, Variablen (aber die sind nur lokal - das ist ein
sehr wichtiges Prinzip dabei => keine Seiteneffekte).
> Prozedural ist also das, wo es dann schon Luxus wie Schleifen und
> so gibt (wie Du ja auch sagst: C).
>
> > (Ruby soll wohl auch - und mittlerweile auch Python - funktionales
> > Programmieren ermöglichen. Ein Grund, sich diese Sprachen vielleicht
> > doch mal anzuschauen :))
>
> Aber eigentlich müßte man dann ja auch in C funktional
> programmieren können: eben, wenn man keine Schleifen und
> Variablen verwendet.
Nein. Nur weil Du das weglässt, ist Deine Programmierung
noch nicht funktional.
Schon globale Variablen schmeissen alles über den Haufen.
Und wie schaut's mit Funktionen als Parameter und Rückgabewerten
aus?
Geht nicht. In C muß man mit Pointern rum frickeln.
Und diese sind obendrein auch nicht alle gleich.
Funktionspointer sind - wenn man den ANSI-C-Standard mal etwas
genauer anschaut - nicht alle gleichwertig.
Wenn man Standardkonform programmieren will, sind Pointer
auf Funktionen unterschiedlicher Prototypen auch nicht
untereinander "verlustfrei" konvertierbar.
Also wird das auch nichts mit higher-order-functions.
> Aber bringt das was? Ich meine, hat das
> Vorteile?
- besser lesbarerer/schreibbarerer Code
- keine Probleme mit Seiteneffekten
- der Code ist gut wartbar
- man kann Probleme prägnant formulieren, sich auf's
Wesentliche konzentrieren, statt irgendwelche implementations-
Eigenheiten berücksichtigen zu müssen.
- ...diverse weitere Vorteile, u.a. auch aus den Sachen,
die mit dem pattern-Matching machbar sind, mit den
Klassensystemen bzw. Modulsystemen, die mit den Sprachen
einherkommen, mit abstrakten Datentypen, funktionalen Objekten
(sofern OO auch vorhanden), und, und, und...
Wenn man dreitausend Zeilen C-Code oder 2000 Zeilen C++-Code
oder Perl-Code gegen vielleicht 120 Zeilen OCaml-/Haskell-/LISP-Code
austauscht, dann weiß man, woran man ist. :-)
Aus dem Code (Haskell als Paradebeispiel) ist - wegen der Syntax -
die Funktionalität gutheraus lesbar.
Man muß die Sprache erst mal beherrschen - klar.
Aber nur weil man C kann, muß man den Code nicht unbedingt
lesen können. Kann man Haskell, wird man fremden Code
recht einfach entschlüsseln können.
Das, was man mit diversen Tools/Dokumentationshilfsprogrammen/...
für C und C++ gerne irgendwie nachträglichnoch dran heften
will, bekommt man da schon aufgrund der Syntax mitgeliefert.
Btw: Haskell-Code kann in zwei Modi geschrieben werden:
Als normaler Quellcode mit eingestreuten Kommentaren,
oder als Textfile mit eingestreuten Programmierkommandos.
Auch das schon zeigt, daß sich da jemand Gedanken gemacht hat...
> Natürlich kann man Schleifen durch Funktionsaufrufe
> ersetzen etc., und das sicherlich eleganter, als es in C möglich
> ist, aber was bringt das unterm Strich?
s.o., oder schau doch gleich mal hier rein, damit Du weißt, wieso
ich denke, daß man - wenn man C++ noch nicht kann, es auch
lieber nicht lernen sollte und Zeit lieber dazu aufwendet,
was vernünftiges zu tun, nämlich Ocaml zu lernen:
http://caml.inria.fr/FAQ/stephan.html
Btw: Die englische Übersetzung des OCaml-Buches ist im Netz.
Dann muß AppleScript wohl noch etwas warten - OCaml hat
Vorrang. :-)
>
> > > > fälschlicherweise benutzt wird für das, was man in C und Co. so
> > > > verbricht; ich denke da eher an Scheme, Haskell, OCaml etc.).
> > >
> > > Kenn die Leute leider nicht.
> >
> > Welche Leute kennst Du denn?
> > C, C++ Perl, Python?
>
> Python auch nicht.
Schade. Ich kenn's auch nicht näher. scheint aber, soweit
ich's mal eines flüchtigen Blickes beäugt habe, schon
ziemlich schnuckelig zu sein. :-)
Viel OO und guten modularen Aufbau soll's haben.
(Und OO da konsequenter als bei Perl).
Vielleicht schau' ich's mir ja auch mal an, kann
eigentlich nicht schaden, denn's ist obendrein
ja doch schoin recht verbreitet...
[...]
> > struct dirent * readdir( DIR * directory )
> >
> > Liefert Dir die Einträge des Direktory nacheinander
> > zurück.
> > Sind die Inhalte eines Directory etwa die Eigenschaften
> > des Aufrufers?
>
> Ja, der Aufrufer hat hier die "Macht". Er kann den return-Value
> überschreiben
Auch in OO-Sprachen hat man die Macht die return-Value
zu überschreiben. Die Return-Value ist die Value, die
MEINE ist, nicht die des gefragten Objektes.
> (ist ja kein "struct dirent *const readdir"), er
> muß *directory beschaffen etc.
Das wäre ja auch noch schöner, wenn die Rteurnvalue
ein const wäre. Dann bräuchte ich ja das Programm
nicht mehr zu starten, wenn ich schon vorher weiß,
was raus kommt. Guck ich eben nach, wie die
Konstante definiert ist. :-)
Daß man dem Objekt nicht die Inhalte überschreiben darf,
sehe ich ja ein. Aber daß ich die vom Objekt erhaltenen
Daten nicht nach meinem Belieben ändern darf, das ist
- mit Verlaub gesagt - recht eigensinnig, ja diktatorisch.
Oder, man könnte auch sagen: Schwachsinnig.
Oder willst Du nun doch funktional programmieren?
Da gibt es keine Zuweisungen. Ist es das, was Du
damit meinst?
>
> > Man könnte auch sagen: sende die Message readdir an das
> > Objekt directory.
>
> Directory ist eindeutig ein Datenfluß, kein Kontrollfluß.
> Außerdem hat readdir nicht die Fähigkeit, auf allgemeine
> Nachrichten zu reagieren (es "ist" kein "Nachrichtenverarbeiter".
> In java würde er also das Interface nicht implementieren, bzw. in
> C++ nicht beerben). Also geht kein readdir.handleMessage oder
> sowas. Könnte man aber bauen, klar.
Es soll ja auch nicht readdir, sondern das Directory befragt werden.
Sende Message "readdir" an Objekt "directory".
Oder anders ausgedrückt: Rufe Methode "readdir" des Objektes
"directory" auf.
>
> > Naja, könnte man noch lange drüber philosophieren.
> > Ist dann letztlich eine Sache der Betrachtung.
>
> Ja, sicher, aber das finde ich interessant. Meistens kommt man ja
> gar nicht dazu. Hin- und wieder ist es aber bestimmt ganz
> nützlich, auch mal über die Grundfesten nachzudenken. Sonst wird
> man später vielleicht selbst einer, der sinnlos oder falsch OO
> oder sonstwas verwendet. Ich meinte, das übt ja und fördert das
> Verständnis. Sowas vergißt man ja auch schnell.
Btw: Was hattest Du eigentlich studiert?
>
> > Ja, prozedural nennt man das typische C-geprogrammiere.
> > Funktional sind Sachen wie in Haskell, hier z.B. Quicksort
> > in Haskell programmiert:
>
> Müßte in Prolog dann auch ganz gut gehen. Ist Prolog vielleicht
> funktional?
Nee.
Ist noch ein anderer Typ von Programmiersprache.
Aus der Logik-Ecke. Die genaue Bezeichnung der
Gruppe von Sprachen müßte man nochmal einen
Informatiker fragen (lernen die sowas?).
> Nee, glaub nicht. Hab Prolog aber auch schon wieder
> vergessen - leider! Konnte man witzige Sachen mit machen.
Du? Informatik?
>
> > qsort :: [Int] -> [Int]
>
> Ne Art Deklaration?
Ja, aber ohne "Ne Art" und mit "!" statt "?".
>
> > qsort [] = []
>
> Was heißt das?
Wird qsort mit [], also der leeren Liste aufgerufen,
ist das Ergebnis ebenfalls [], also eine leere Liste.
>
> Quicksort war "Teile-Und-Herrsche", bis man über zwei Elemente
> herrscht, die man ggf. austauscht, und dann sortierte man die
> geteilten (und inzwischen sortierten) Ketten, richtig? Oder
> verwechsel ich das schon wieder?
Häh?
Immer diese seltsamen Metaphern... ;-)
>
> > qsort (x:xs) = qsort [ y | y<-xs, y <=x] ++ [x] ++ qsort [y | y<-xs, y > x ]
>
> Verstehe ich überhaupt nicht, kenn auch die Syntax überhaupt
> nicht.
(x:xs) ist ein Pattern-match, das eine Liste in erstes Element,
das "x" vorm Doppelpunkt und den tail der Liste
(das "xs" nach dem, Doppelpunkt) aufsplittet.
Das an die Funltion übergebene Argument wird also aufgesplittet.
Pattern match eben.
Der Rückgabewert ist dann ein erneuter Aufruf der qsort-Funktion
(Hallo rekursion!) mit einer List Comprehension als Parameter
und Listenverkettung ist auch noch dabei.
Ne List-Comprehension ist eine recht elegante Schreibweise,
eine Selektion (Filter) auf einer Liste durchzuführen.
Sieht doch von der Syntax her so aus, als daß es jeden Mathematiker
fröhlich lächeln läßt: [ y | y <- xs, y<=x ]
Es handelt sich um eine Listenoperation (erkennt man an den
"[" und "]" => Das Ergebnis ist also ne Liste.
Der Wert vor dem "|" ist das Element, das zurückgegeben wird;
nach dem "|" folgt die Definition, wie dieser Wert denn
erhalten wird => es ist xs, also tail des Funktions-Arguments/Parameters.
Und die Bedingung steht hinter dem komma: y <=x
++ hängt zwei Listen aneinander
Man hat also drei Listen mit ++ zusammengebaut.
Die erste : Listcomprehension, die zweite: Liste mit x als Element,
die dritte noch ne comprehension.
Das ganze als Argument von qsort.
qsort wuselt sich solange durch, bis es mal auf eine
empty list ("[]") stößt. Dann gibt es nur []
zurück. Ansonsten eben entsprechende dem, was in den Bedingungen
noch anzutreffen ist...blah, sülz, laber....
So, genug. Willste mehr wissen, musste Bücher kaufen. ;-)
> Ach so, moment, Du suchst Dir irgentwo ein X, packst links
> alles hin, was kleiner ist, und rechts, alles was größer ist, ja?
> Was macht hier xs eigentlich? Erklär mal, sieht nett aus :)
>
> > Sieht bedeutend besser aus, als Quicksort in C. :)
>
> Irgentwie kompakter :)
Sachickdoch. :)
>
> > ein Ergebnis. Es ist völlig unerheblich, ob die Argumente
> > und returnvalues nun Variablen im klassischen Sinne sind,
> > oder ob es Funktionen selbst sind.
>
> Ahh ja, genau so war das.
Das steht in Deiner Aufzählung in Punkt 5: Funktionen sind
first class values.
Da macht Programmieren dann Spaß! :)
> Hab ich nie benutzt, glaub ich.
Wenn Du die Sprachen nicht benutzt hast, wirst Du auch
dieses feature nicht benutzt haben.
Dewegen kennst Du die Vorzüge nicht. Deswegen kannst Du Deinem
zukünftigen bröthcengeber diese nicht verklickern.
Deswegen glauben die Brötchengeber, daß in den Unis nichts
fortschrittliches gelehrt wird.
Nur, weil man sich das nicht näher angeschaut hat.
Hättest Du es Dir näher angeschaut, hättest Du aber
vermutlich schlechte laune, wenn Du mit C++/Java arbeitest.
Also schongut gelaunt auf dr Arbeit ein freundliches Gesicht
machen und die guten Dinge, die man der Uni hätte verdanken können,
ignorieren. Dann spricht man von Bildungsmisere und davon, daß
die Unis praxisnäher ausbilden sollten.
Dabei sollten die Leute in den Firmen lieber mal die Augen auf machen
und etwas Uni-näher ihren Arbeitsalltag gestalten, also z.B.
effektive Programmiersprachen einsetzen.
Aber eher setzen die Unis auf Windoof und C++, als daß sich
die verbretterten Unternehmer - jammernd, daß sie keine
Fachkräfte kriegen - mal anschauen, was sie alles verpassen....
..so, genug geschwallt.
Es wird schon dunkel, verdammte Scheisse. Vielleicht gehe ich nachher
doch noch nen Bier trinken, bevor Ostern völlig vorbei ist. ;-)
> In der
> Praxis wohl auch seltener zu finden.
Eben: Dummheit stirbt nicht aus.
Dummheit ist die einzige Konstante der Arbeitswelt und
damit Konjunkturunabhängig.
> Eine ideale
> Programmiersprache müßte es gestatten, sozusagen "sauber zwischen
> den Konzepten zu wechseln", wie man es gerade braucht.
Schau Dir mal OCaml an. Ist was feines.
Mir ist nur eine Sprache bekannt, die noch mehr
Programmierparadigmen unterstützt, ich denke wohl
alle vorhandenen, also auch Prolog-Style.
Die gute heißt Oz und ist in der Programmierumgebung
MOzart wieder zu finden.
Da hat man sich wohl speziell zum Ziel gesetzt, alles
vorhandene auch zu nutzen.
Scheint auch extrem effektiv zu sein, was die Programmierung
angeht; In den texten dazu stand mal was von einem
Stundenplan-Planer. War in der Sprache wohl ein Klacks.
> Also das
> ich z.B. in ne OO Methode ein funktionales "Teilprogramm" haben
> dürfte. Aber sicherlich schwer bis gar nicht realisierbar.
Ist das sinnvoll?
In Ocaml bigt's z.B. funktionale Objekte.
Ist ein anderer Ansatz von dem, was man unter Objekten
versteht.
>
> > Man kann also Funktionen
> > schreiben, die Funktionen zurückliefern und diese kann man
> > dann als Argumente an andere Funktionen übergeben.
>
> Ja, dann muß man nur die "Regeln" aufschreiben, und die
> "Ablaufsteuerung" ergibt sich daraus. Meistens jedenfalls :)
Man kann z.B. mit der Funktion filter folgendes nettes machen:
filter isEven [2,3,4,5]
liefert eine Liste mit allen geradzahligen Elementen der als letztes
argument übergebenen Liste
isEven ist eine Funktion, die prüft, ob eine Zahl gerade ist,
oder nicht.
Wenn man statt isEven eine beliebige andere Funktion
einsetzt (und die Parameter entsprechend so übergibt,
daß da mit den Typen alles stimmt), dann kann man dahinter
im Prinzip beliebig komplizierte Sachen verstecken.
filter isSorted [ [2,3,4,5],[3,4,44,7],[],[4] ]
gibt alle Listen zurück, die sortiert sind....
...usw.
Oder mit der Funktion map kann man eine Funktion auf
die Listenelemente anwenden, ....
Diese Möglichkeit ist echt wat feinet. :)
>
> > Coredumps kann es prinzipiell nicht geben.
>
> Na gut, die gibt's ja nur, weil C sich defaultmäßig nicht um
> SIGSEGV kümmert, und es sowas überhaupt geben darf. In meinen
> Augen ist das aber nur ne Abschaltung theoretisch geforderter
> Sicherheit, um ein bißchen Performance zu gewinnen. Java kennt
> solche Probleme ja auch nicht, oder Ada, aber beide sind doch ein
> bißchen langsamer, weil eben mehr zur Laufzeit gemacht werden
> muß, als: "Nimm da mal vier Byte (was auch immer das ist), und
> interpretiere das mal als ne Ganzzahl, in der Hoffnung, daß
> jemand vorher da auch wirklich ne Ganzzahl hingeschrieben hat.".
> Ist ja auch mehr "Versprechen-Und-Glauben" als Programmieren :)
Also, ich kann Dir die Details nicht nennen, dazu bin ich
in der Materie nicht tief genug. Aber wenn Du mal in
comp.lang.functional gelegentlich mitliest, und dann
da die Freaks loslegen, hört man immer wieder davon, wie
kruder, unausgegorener Kack doch C++ und Java sind....
[...]
> > aber ist die Implementierung sauber, kann man keine Coredumps
> > durch dumme Programmierung hervorrufen. In C kann man das mit einem
> > Einzeiler (sofern's ulimit nicht auf 0 gestzt ist...).).
>
> Man *kann* das auch in C verhindern / behandeln.
Man kann auch in C OO-programmierung machen...
...wenn man sich das OO-System selbst zusammen baut.
Ciao,
Oliver
Mehr Informationen über die Mailingliste linux-l