[linux-l] RS-232 oder USB lesen mit (Schauder...) Java Os-unabhaengig

[Volker Grabsch]

On Thu, Sep 22, 2005 at 02:09:37AM +0200, Oliver Bandel wrote:
> [...]
> > Von daher ist die Begrifflichkeit "schon beim Compilieren" nichts-
> > sagend, wenn man erst gar nicht compilieren braucht.
> 
> Das ist ja nun ein Argument rhetorischer Art.

Das ist überhaupt kein Argument, sondern nur eine Klarstellung von
Begrifflichkeiten.

> Dann ist es eben Python, das compiliert.

Richtig erkannt. Das habe ich aber auch gesagt.

> Was, wenn der Code nicht compilierbar ist?
> Was macht den Python dann?
> Wie weisst Du das dann?

Syntax- und Laufzeitfehler werden unter Python gleichartig behandelt:
Mit Exceptions. Wenn ich also z.B.

	import meinmodul

mache, und in mainmodul.py ein Syntaxfehler steckt, bricht dieser Import
mit ner Exception ab. Ob ein Fehler beim Compilieren oder direkt beim
Starten (bevor irgendwas anderes passiert) auftritt, ist praktisch
irrelevant, wenn nach dem Compilieren sowieso immer das Starten erfolgt.

> (BTW: Wie ist das implementiert? läuft der Compiler als Daemon?)

Quatsch. Wenn du

	python meinprogramm.py

startest, dann compiliert er (falls nötig), legt ein meinprogramm.pyc
an (falls Schreibrechte im Verzeichnis vorhanden), und dann startet er
es. Es ist also quasi ein automatisches

	make meinprogramm.pyc && "python-run" meinprogramm.pyc

Also ganz einfach. Der Verzicht auf einen extra Compilierungs-Schritt
macht die Sache etwas bequemer zu handhaben. Inhaltlich ist das
natürlich kein großer Unterschied.

Ich möchte deshalb, aus rein praktischen Gründen, keine Unterscheidung
machen zwischen "Compiler-Fehlern" und "Laufzeitfehlern sofort beim
starten des Programmes". Von mir aus kannst du auch die Laufzeitfehler
(Exceptions), die Python beim Starten des Programmes eventuell
generiert, ebenfalls zu "Compiler-Fehlern" zählen. Insbesondere zählen
für mich auch die Fehler dazu, die meine Testsuiten erzeugen. Zwischen
all diesen Fehlern macht es aus Programmierer-Sicht keinen Sinn, zu
unterscheiden, welche "eher" auftreten.

Laufzeit-Fehler, die nur unter gewissen Bedingungen auftreten, oder die
ersten nach gewissen Interaktionen auftreten, habe ich damit nicht gemeint!

> > Abgesehen davon vereinigt eine gute IDE sowieso die beieden Schritte
> > "Compilieren & Starten" auf Knopfdruck. Und das machst du ja sicher
> > auch, oder?
> 
> IDE?
> 
> brrr.... als Kommandozeilen-Junkie und Klicki-Bunti-Aversionist
> und "ick liebe meeen vim"-Mensch nehme ich natürlich keine IDE. :)

Mag sein, geht mir genauso (obwohl ich öfters auch xemacs nehme). Aber
auch du wirst dann an der Komandozeile sowas wie

	make meinprog && ./meinprog

stehen haben, das du "Pfeiltaste Hoch", "Enter" auswählst, oder? Ich
wollte nur darauf hinaus, dass du gleich nach dem Compilieren auch
startest.

> > Wieso? Wenn du nach dem Compilieren sowieso das Programm startest,
> > kann es dir doch egal sein, wenn es erst beim Starten den Fehler
> > ausgibt.
> 
> Nein. Wenn es ein Fehler ist, der erst zur Laufzeit auffällt und vielleich erst
> nach 10.000 testfällen, weil es sich um eine komplexe Software handelt,
> oder vielleicht erst dann auffällt, wenn der entsprechende Testfall beim Anwender
> ausgetestet wird, dann ist das blöd gelaufen.

Von dieser Sorte von Fehlern habe ich nicht gesprochen!

Dass der Ocaml-Compiler auch solche Dinger enttarnen kann, finde ich
beeindruckend, jedoch waren bisher die einzigen derartigen Fehler, dass
man sich im Methodennamen vertippt oder eine falsche Anzahl von
Argumenten übergibt. Und diese Fehler fallen sofort auf, wenn man die
Methode auch nur irgendwie aufruft. Insbesondere also fallen sie
garantiert bei meinen "normalen" (inhaltlichen) Testcases auf. Extra dafür
welche schreiben brauchte ich bisher nie.


> > Die Unterscheidung von "Fehlern zur Compilierungs-Zeit"
> > und "Fehlern zur Laufzeit" macht keinen Sinn, wenn es keinen
> > umständlichen extra Compilierungs-Schritt gibt.
> 
> ?

Sorry, ich meinte: wenn es keinen "expliziten" Compilierungs-Schritt
gibt. siehe oben.



> > > Code, der compiliert werden kann, ist schon deshalb recht solide.
> > > Man kann nicht einfach irgendwas zusammen bauen und zur Laufzeit kracht's.
> > > Fehlerhafter Code fällt dann schon auf, bevor er laufen könnte.
> > 
> > Okay, lass uns bitte von diesen Begriffen wegkommen, da sie keinen
> > Vergleich zwischen Python und OCaml ermöglichen. Wenn das Programm
> > beim Starten mit einem Fehler abbricht, ist das genauso gut, als
> > wenn es beim Compilieren abbricht, weil man beides sowieso
> > hintereinander macht.
> 
> Nein. Da bin ich vollkommen anderer Meinung.
> 
> Ich habe mal im bereich Softwaretest gearbeitet. Mit einem wirklich
> beknackten Tool sollte ic C-Code checken.
> Da mussten diverse Branches abgetestet werdn, oder mindestens soundsoviel Prozent.

Keine Ahnung, womit du da gearbeitet hast, aber du willst doch nicht
von *diesen* Erfahrungen irgenwie auf Python schließen, oder? Das ist
unsachlich und weit hergeholt. So kann man nicht diskutieren.

Meine Testcases gingen schnell zu schreiben und schnell durchzulaufen.
"Umständlich" ist an Python kaum etwas.

> Wenn man da so viele Wochen braucht, nur um den Code abzusichern,
> inhaltlich aber auch bzgl. potentieller Abstürze, etc. dann ist das der
> falsche Weg, wenn man die auf falshen typen beruhenden Fehler nicht schon
> garnicht erst abtesten müsste.

Wiegesagt brauche ich keinen extra Typcheck. Lapalien wie falscher
Methodenname etc. fallen ganz automatisch auf, wenn man diese Routinen
nur aufruft. Und ja, ich gehe natürlich davon aus, dass meine Testsuite
jede Funktion / Methode mindestens einmal aufruft. Wenn das nichtmal
der Fall ist, dann sollte man sowas nicht "Testsuite" nennen, und erst
recht nicht von seinem Code behaupten, er wäre gut getestet :-)

> Es ist besser, der Fehler fällt so früh wie möglich auf.
> Um so weniger Zeit wird für's Suchen aufgewendet.

Ob er beim Compilieren oder beim Rennen der Testsuite auftaucht, macht
für mich zeitlich keinen Unterschied. So schnell kann ich gar nicht
gucken, wie Python das Zeug byte-compiliert, gestartet, und die
Testfälle durchgeochst ist.

> > Kommen wir nun zu einem "echten" Unterschied, den du wahrscheinlich
> > meinst: Es kann sein, dass zur Laufzeit nur in besimmten Situationen
> > Typfehler auftauchen, die du bei einem Ocaml-Programm gleich zu anfang
> > bemerkst, aber in Python erst beim gründlichen Austesten.
> 
> Oder erst der Anwender... vielleicht erst in Monaten oder Jahren.
> Aber genau DANN, wenn es nicht sein soll. ;-(

Die "Typ-Fehler", von denen ich rede, fallen bei Python ziemlich schnell
auf. Zwar nicht beim Compilieren, aber sofort beim Starten des
Programmes bzw. beim Aufruf der fehlerhaften Funktion/Methode.

> > Dies ist zwar tatsächlich ein Problem, aber kein allzu großes: Wenn
> > du sauber programmieren willst, also dein Ziel stabiler Code ist
> > (davon reden wir ja die ganze Zeit), dann wirst du ohnehin alles
> > gründlich austesten müssen.
> 
> Selbstverständlich.
> 
> 
> > Dann wirst du sowieso inkrementell
> > Programmieren: Immer nur kleine Sachen ändern, und gleich austesten.
> > Sobald es plötzlich einen Fehler gibt, kannst du seine Ursache sehr
> > schnell eingrenzen
> 
> Aber nicht, wenn der Fehler einer eben gemachten Änderung womöglich erst
> später auffällt.

Das sollen die Testcases verhindern. Und ich jage nach jeder größeren
Änderung die Testsuite rüber, und ergänze vllt. noch ein paar Tests.
Dann arbeite ich weiter, ändere Code, füge welchen hinzu, jage wieder
die Testsuite rüber. Das geht wirklich fix. Und du machst das doch
genauso bei der Entwicklung, oder? Und zwar solange, bis alle Tests
erfolgreich waren.

> > auf die Stelle, die du eben geändert hast. 100
> > Zeilen Code umschreiben, und dann erst zu testen, ist kompletter
> > Wahnsinn und viel zu riskant.
> 
> Kommt drauf an. :)
> Wenn die Sprache einem dabei hilft, daß es auch mehr als zwei Zeilen
> sein dürfen, die man ändert. ;-)

Klar doch.

Übrigens hat Python noch eine ganz andere Art der Fehlervorbeugung:
Einfache Syntax. Keine Semikola (pro Befehl eine Zeile), keine
geschweiften Klammern o.Ä. (wird durch Einrückung geregelt), u.s.w.
Wegen dieser sehr einfachen Syntax wird Python manchmal sogar
"Pseudo-Code" genannt, aber dieser Code läuft! Außerdem wird in
Python vermieden, dass man zum Verstehen des Codes "um die Ecke denken"
muss.

Diese Beschränkung auf das Einfache und Übersichtliche ist es, was
Python für mich so interessant macht. Man macht schon beim Schreiben
viel weniger Fehler, und während ich in Java ständig ein der API
nachschlagen musste, sind die Funktionen und Klassen in Python in
einer flachen Hierarchie und einfach gehalten, sodass man sich das
alles problemlos merken kann. Ich musste für gleichartigen Python-Code
(bei Ruby war das übrigens  genauso) viel weniger Nachschlagen ("wie war
das nochmal?"), als ich es bei meinem Java-Projekt musste.

Ich denke, dieser Vorteil dürfte auch auf Ocaml zutreffen, bin mir aber
nicht ganz sicher. Kannst du dazu was aus Erfahrung sagen?


> > Aber was bedeutet "testen"? Testen heißt ja nicht bloß "Syntax-Check"
> Eben, den macht der Compiler ja schon.
> und wenn er die Typen auch gleich testet, um so besser!

Klar, aber wenn er nur Fehler findet, die meine Testsuite genauso finden
würde (ohne dass ich dafür irgendwas extra schreiben brauch), dann ist
das ein Feature, das ich nicht brauche.

Jedoch Ocaml scheint noch ein paar Sachen mehr zu prüfen. Und *das*
macht die Sache dann doch wieder interessant für mich. Ich werde es auf
jeden Fall mal anschauen. Gibt es eigentlich noch andere Sprachen, die
ähnlich streng wie Ocaml sind? Also statische Typisierung, die aber
automatisch erkannt wird, etc.?

> > Logikfehler, Denkfehler, Designfehler sind nämlich das wirkliche
> > Problem, dem zu zuleibe rücken musst.
> 
> Das muß man doch sowieso machen, jedenfalls wenn man ernsthaft vor hat,
> das Programm auch das machen zu lassen, was man von ihm erwartet.
> 
> Wenn man aber zusätzlich noch die Aufgaben des Compilers übernehmen muß,
> dann ist das unnötige Mehrarbeit für den Programmierer.

Dem stimme ich vollkommen zu. Das war bei meinen Programmer bisher
jedoch nicht der Fall.

> > Wenn man Testfälle aber sowieso benutzt, weil man ja sowieso Laufzeit-
> > Tests braucht, dann wird beim Starten des Test-Programmes sowieo alles
> > aufgerufen und alles abgearbeitet, was du programmiert hast.
> 
> Ob es alles ist, das laß ich mal dahin gestellt,
> gehe aber davon aus, daß es höcht wahrscheinlich NICHT so ist.

Bei mir schon. Aber 

> Gerade Code mit vielen Bedingungen kann zu Problemen führen.
> Wenn man dann vergisst, einen Fall abzufragen, dann ist das
> möglicherweise genau der Fall, wo es probleme gibt - die aber
> eben möglicherweise nicht gleich auffallen.

Das mag sein. Derartigen Code habe ich bisher jedoch kaum geschrieben.
Bei meiner aktuellen Applikation liegen die Schwierigkeiten in ganz
anderen Bereichen.

> Wie schön, daß man bei OCaml mit dem Pattern-Matching
> arbeiten kann. Wenn man einen Datentyp definiert und
> mit einem Pattern-Match einzelne Fälle abtestet,
> und dabei einen vergisst, dann schneisst der Compiler eine
> Warnung raus:
> 
> ===================================================================
> first:~ oliver$ cat beispiel.ml 
> type blah = Blih | Blah | Blubb | Untested_case
> 
> let string_of_type der_typ = match der_typ with
>         Blih -> "Blih"
>       | Blah -> "Blah"
>       | Blubb -> "Blubb"
>     
> first:~ oliver$ ocamlc beispiel.ml 
> File "beispiel.ml", line 3, characters 29-118:
> Warning: this pattern-matching is not exhaustive.
> Here is an example of a value that is not matched:
> Untested_case
> first:~ oliver$ 
> ===================================================================

Das ist ein wundervolles Feature, beeindruckend!

> Finde ich geil, sowas. :)

Solchen Code habe ich bisher nicht schreiben müssen, bei mir waren alle
Fallunterscheidungen mit einem "else" am Ende versehen, sodass ein
solcher Test nicht nötig ist. Aber trotzdem ist das cool, muss ich
zugeben. :-)

> > fallen Typfehler (d.h. bei Python: Aufrufen von nicht existierenden
> > Methoden) automatisch mit auf.
> 
> Naja, und wenn die Methode nicht aufgerufen wird, weil der Testfall
> noch nicht definiert ist?

Eine Testsuite, die es nichtmal packt, jede Methode mind. einmal
aufzurufen ... was ist den das??


> Vor einer Weile habe ich mir mal Objective-C angeschaut.
> Ist ja mit late binding extrem Flexibel. Das hat ja auch so seine
> Vorteile. :)
> Aber kaum hatte ich mal mit ObjC etwas herum probiert... und mich schon
> gefreut, wie flexibel man damit ist, da kam schon genau SO ein Fehler.
> 
> Und DAS hat mich vielleicht genervt, ey!
> 
> Aber wirklich!
> 
> Nö, da lieb' ich doch den auf die Finger klopfenden OCaml Compiler. :)

Nenn mal bitte dein Beispiel. Was hattest du denn gemacht?


> > Wenn du also sowieso inhaltliche Tests machst, hast du automatisch
> > auch Typ-Tests.
> 
> Je früher ein Fehler gefunden wird, desto besser.
> 
> Habe lange genug in Perl gemacht.
> Habe damals auch so geredet. Ich sehe das mittlerweile anders.
> 
> Bei Perl war ich dann froh, daß es "use strict;" gibt.

Hab ich auch immer benutzt. :-)

> Aber das hilft auch nur bedingt, und manche Fehlermeldungen
> sind echt strange. Naja.
> Solange es nicht zwingende Gründe für so eine dynamische Sprache gibt
> (und ich denke: die gibt es nur sehr selten), fährt man besser
> mit so einem rigiden Aufpasser, der Syntax, typen, Vollständigkeiten
> von Pattern-Matches abtestet.

Da ist was dran.

Eventuell reimplementiere ich meine Applikation nicht in Python, sondern
Ocaml.  :-)

> > Und im "Ändern - Testen - Ändern - ..."-Zyklus
> > werden dir Typfehler entsprechend auch "sofort" angezeigt, weil
> > du ja nach jeder Änderung automatisch deine Testsuite drüberjagst.
> 
> Du gehst davon aus, daß Deine testsuite jeden Fehler findet.
> Mit dieser Annahme begesht Du einen Fehler.

Nö, nicht alle. Schon gar nicht alle inhaltlichen. Aber alle vertippten
Methoden-Namen findet es.

> Das mag für die Heimprogrammierung genügen, und das mag auch
> in der Industrie üblich sein, aber letztlich dennoch IMHO
> fahrlässig.

Das stimmt. Aber Python oder Java sind ja noch gutartig. Wer mit C
arbeitet, *der* ist fahrlässig. Huch, hab ich da grad was gegen Linux
gesagt?  :-)

> Gut, daß Du nicht sicherheitskritische SW schreibst...
> ...obwohl: Selbst in den Industriezweigen arbeitet man
> mit Sprachen und testtools, die unverantwortlich sind.

Würde ich sicherheitskritische Anwendungen schreiben: Glaub mir, ich
würde ganz andere Maßstäbe ansetzen. Ocaml ist von der Warte heraus das
beste, was ich gesehen habe (hab mich mittlerweile schon etwas schlauf
gemacht). Gibt's da eigentlich von der Code-Sicherheit was
vergleichbares, oder steht Ocaml da allein auf weiter Flur?

> [...]
> > Wenn dir Ocaml hingegen irgendwelche Sachen durch die Typisierung
> > unnötig schwer macht
> 
> macht es nicht.
> Warum sollte eine Sprache, die einem die Fehler früh aufzeigt,
> einem bei tests das leben schwer machen?
> Keines wegs.
> Im gegenteil: ich kann mich bei der programmierung dann auf die
> inhaltlichen Tests konzentrieren, und mir fallen nicht andauernd
> irgendwelche casts und so'n Blödsinn auf die Füße!

Mach ich genauso. Nur inhaltliche Tests. Aber wiegesagt war da bisher
auch noch nichts groß Kritisches dabei.

> > Wenn dir Ocaml ein sicheres Gefühl bei deinem Programm verleiht,
> > ohne dass du Testfälle geschrieben hast, dann ist das eine trügerische
> > Sicherheit und sehr gefährlich.
> 
> nu iß aber ma gut, ey!

War ja nur ne Vermutung. Ich wollte damit nicht sagen, dass du deine
Software unzureichend testest. Das kann ich ja überhaupt nicht wissen.

> > Stabile Software braucht
> > in jedem Fall automatisierte Laufzeit-Tests! Das wird sich später
> > 100fach wieder auszahlen, wenn du Bugs produzierst, die sich nur
> 
> Danke, danke, aber ich bin derjenige, der für seine Testgeilheit
> meist immer erst für verrückt erklärt wurde, und hinterher am schnellsten
> fertig war. :)

Hehe. Kenn ich irgendwie ...

> Ich meine... mal das ganze anders herum: Da man eh - wenn man es so wie
> Du hier vertrittst - diverse tests durchführt, reicht ein Compiler,
> der nicht nur auf typprüfung verzichtet, sondern auch die Syntax nicht
> korrekt prüft.
> Der übersetzt also irgendwie irgendwas, und wenn das programm dann
> zur Laufzeit Müll fabriziert, weiß man ja, daß man wohl einen
> syntaktischen Fehler in seinem Code hat.

Wenn Python das machen würde, wäre ich persönlich nicht traurig, viele
andere aber sicher schon. :-)

> Da man das eh mit zig testcases automatisiert abtestet, braucht der Compiler
> auch nicht die Syntax nicht zu prüfen.
> Es richt, wenn er korrekte Syntax voraussetzen kann und dann bei koirrekter Syntax
> korrektes Compilat erzeugt.
> 
> Na, gehst Du auch so weit noch mit?

Nicht ganz. Bei Typfehlern, fehlerhafter Syntax, etc. sollte zumindest
eine Exception geworfen werden.

So gesehen geht Python fast so weit, wie du es beschreibst. Zum
Beispiel könnte ich via ein Python-Programm schreiben, wo u.a. drin
steht:

	import meinmodul

Wenn jetzt "meinmodul.py" einen Syntaxfehler enthält, bekommt das Python
erst mit, nachdem es "meinmodul" importieren soll. Dann erst erzeugt es den
Bytecode (meinmodul.pyc), falls nötig, und lädt das Modul. Hatte
meinmodul.py z.B. einen Syntaxfehler, scheitert obiger Befehl mit einer
Exception.

Da dieser Fehler aber sofort beim Starten des Programmes auftritt, ist
mir das egal. Ob nun beim Compilieren oder ein paar Millisekunden später
beim Starten / Testen, das kümmert mich nicht. Genau sowas meinte ich
damit, dass "Fehler beim Compilieren" und "Laufzeit-Fehler beim
Programmstart" kein wirklicher Unterschied sind. Gerade in Python ist
das sogar genau gar kein Unterschied.

Was du jedoch an möglichen Fehlern beschreibst, die der Compiler
entdecken kann, und die erst mitten im Programm-Ablauf bei bestimmten
Interaktionen auftreten, da gebe ich dir recht: Da ist eine größere
Strenge sehr wünschenswert.

> [...]
> > Aber wiegesagt, das ist die "pythonische Sicht", und diese Argumentation
> Nein, das ist DEINE Sicht der Argumentation.

Okay, ich werde besser nochmal konkreter. Folgendes ist eine gängige Sicht
von Python-Programmierern, d.h. die "pythonische Sicht":

Ewiges Typen-Tippen und Casten (wie es z.B. in Java der Fall ist)
provoziert mehr Fehler als es verhindert. Wenn man sowieso testet,
spart man am Ende sehr viel mehr Zeit, als man anfangs für das formale
Befriedigen des Compilers gebraucht hat.

Diese Argumentation geht aber wiegesagt vorallem gegen Java, nicht
gegen Ocaml.


> [...]
> > Ich weiß nicht, ob eine statisch typisierte Sprache jemals so flexibel
> > sein kann wie z.B. Ruby oder Python.
> 
> Ist ja die Frage, ob man diese Flexibilität wirklich benötigt, oder sie nicht nur
> aus mangelnder Programmierdisziplin gerne in kauf nimmt, weil einem
> die viell. recht häufigen Typ-Probleme niht immer vor die Nase gehalten werden.

Nee, nicht Typ-Probleme, die gibt's ja sowieso, sondern ständiges
Wiederholen, was wann welchen Typ hat. Das ist vorallem in C++ / Java
nervend. Ocal ist offenbar anders.

> Ich hätte ja bei Perl bleiben können. Anfangs dachte ich auch immer:
> Naja, OCaml mag viell. für größere projekte sinnvoll sein, aber nicht für
> kleinere Sachn, denn die kann man in Perl schneller zusammen hacken.

Hey, bitte schließe nicht, was die Sauberkeit des Programmierens angeht,
von Perl auf Python. Auch die Python-Leute distanzieren sich sehr von
Perl.

> perl nehme ich nur noch sehr selten, seit ich OCaml nutze.
> So ungefähr, wie ich C kaum noch nahm, seit ich Perl-te.
> Der vermeintliche Vorteil dieser Sprachen ist aber oftmals ihr Nachteil.

Bitte schließe nicht von Perl auf alle dynamsichen Sprachen,
insbesondere nicht auf Python. Mag sein, dass Python nicht ganz so
streng ist wie Ocaml, aber es ist sehr viel strenger und sauberer
als Perl. Vorallem auch die APIs. Sie machen einem unsaubere "Hacks"
schwer (weil sie nicht dafür ausgelegt sind), aber z.B. bei CGI-Scripten
kriegt man saubere Sachen damit schneller gebacken als z.B. in PHP.

> Mag sein, diese sind für manche Anwendungen doch besser geeignet,
> aber IMHO muß die Anwendung solcher Sprachen (mit ihrer erhöhten
> Bug-Wahrscheinlichkeit, die sie einbringen)  ausserordentlich begründet
> werden, zumindest, wenn man wirlich solide Software schreiben will
> und nicht nur herum daddeln.

Na, na ... ich bemühe mich sehr, sauber zu programmieren. Nur, weil ich
nicht Ocaml sondern Python benutze, heißt das nicht, dass ich nur
"herum daddel".

Zum Thema dynamische Sprachen: Ich bin mir sicher, dass mein Python-Code
wesentlich sauberer ist und fehlerfreier, als entsprechender Java-Code.
Und dass mich das insgesamt sehr viel weniger Arbeit in Python kostet,
trotz laschem Compiler. Denn der Java-Compiler zwingt einem zum Erfüllen
von sinnlosen Formalismen, und das ist IMHO noch viel schlimmer, weil
man daran gehindert wird, sich auf das Wesentliche zu konzentrieren.

> [...]
> > Achso? Nur für Geld würde sich das lohnen? Also, das wäre für mich der
> > letzte Grund für so eine Entscheidung. Es sei denn natürlich, ich werde
> > direkt nach Arbeitsstunden bezahlt. ;-)
> > 
> > Aber was wäre, wenn du mit Python schneller zum Ergebnis kommst, also
> > es dir Enticklungs - *Zeit* erpart. Würde es sich dann nicht auszahlen?
> 
> Wenn es einen Anwendungsfdall gibt, bei dem das der Fall ist,
> mag Python sich anzushauen auch noch Sinn machen.
> 
> Nachdem "die dynamischen Verlockungen" von Perl mir das Hirn verdreht hatten,
> dachte ich auch, das muß alles so sein.

"Auch" ???  Schließe bitte nicht von dir auf mich.

Ich habe vor Python mit Pascal, C++, Java, etc. gearbeitet. Okay, auch
mit Perl und Shell-Script und anderen Sachen, aber die großen Dinger
stets in "stregeren" Sprachen gemacht. Python ist die erste /dynamische/
Sprache, in die ich genug Vertrauen gesetzt habe, um damit etwas größeres
zu machen. Dynamische Sprachen sind für mich keine Selbstverständlichkeit,
ich bin erst relativ spät dahin gekommen.

> Erst, als ich mit OCaml dann mal
> was anderes sehen durfte (war ein harter Kampf, am Anfang, wenn einem
> ständig irgendwelche Typfehler gemeldet werden) und mich da auch dran gewöhnt
> hatte, und als ich dann sah, wie viel besser man damit komplexe Probleme
> lösen kann (während einem Perl mit seiner Abwasser-Syntax das Hirn verknotet),
> wußte ich, daß das so viel besser ist.

Gut, so hart wird das für mich wohl nicht werden. Im Gegensatz zu C++
oder Java sieht Ocamls Compiler immer noch freundlich aus.

> OK, Python ist, nach allem, was ich mitbekommen hab, wesentlich aufgeräumter als Perl.
> Aber sicherlich nicht so wie OCaml.

Das ist wahr.

> Und warum soll ich auf die Sachen, die ich bei OCaml jetzt schon habe,
> bei Python noch drauf warten? (Du schriebst da mal was zu zip() und
> irgendwelchen neuen features, die nicht extra Listen erzeugen.
> => List.iter sage ich nur. :)

Das ist ein Missverständnis. Ich sagte, diesen Kram gibt's ab Python 2.4
Aber das aktuelle Release von Python *ist* nunmal 2.4  ... ich wollte
damit nur sagen, dass man die aktuelle Version nutzen muss, um meine
Beispiele auszuprobieren. Das ist alles Stand der Technik, was ich hier
erzähle!

> > Das weiß ich natürlich nicht. Aber abgesehen von eventuellen Vorteilen
> > bei der Typisierung ist OCaml ja ziemlich festgefahren auf funktionale
> > Konzepte.
> 
> Du redest da gerade Müll.

Sorry, mein Fehler.

> Das schöne an OCaml ist, daß es neben funktionaler Programmierung auch imperative
> Programmierung und objektorientierte Programmierung erlaubt.
> Ist also gerade NICHT festgefahren auf funktionale Programmierung.
> Das ist es doch gerade, was programmieren in OCaml so angenehm macht:
> Löst man das Problem am besten funktional, macht man es so.
> Löst man das Problem am besten imperativ, macht man es so.
> Löst man das Problem am besten objektorientiert, macht man es so.
> Alles andere wäre Dogmatismus.

Dito für Python.

> Und obwohl OCaml da so viele Möglichkeiten
> bietet, ist es schön streng beim Prüfen des Codes.

Python glänzt durch eine einfache Syntax. IMHO auch einfacher als Ocaml.
Dafür ist es bei den Typen nicht so streng wie es sein sollte, das stimmt.

> > In Bereich Software-Design hättest du in Python wesentlich
> > bessere Karten, IMHO.
> IMHO nicht.

Mal sehen. Das werde ich ja herausfinden. Sobald ich in der Uni bin,
saug ich mir Ocaml (ist schon im Aptitude alles ausgewählt :-)).


Viele Grüße,

	Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR