Das deutsche Python-Forum

Auch wenn mein Wissen und meine Erfahrung gegenüber Eurer gegen Null geht, erlaube ich mir trotzdem, meinen Senf abzugeben:
Die Frage, mit welcher Sprache und welchen Umgebungen der selbstbestimmte Einsteiger beginnt, halte ich nicht für so entscheidend. Lernen Kleinkinder in China, auf Borneo, in Frankreich oder auf Grönland nicht alle ihre Muttersprache? Macht die Sprache einen Unterschied? Das Klima? Die Umgebung? Wohl eher nicht.
Kinder lernen ihre Sprache und deren Anwendung durch Hören. Durch Beobachtung. Durch Nachahmung. Niemand lernt eine Sprache allein mit einem Wörterbuch.

Ok, ich selbst eigne mich vielleicht nicht unbedingt als Referenz, aber doch als Beispiel: Ich beschäftige mich seit etwas mehr als 2 Jahren mit Python. Wenn ich so lese, dass sich ein Programmierer eine neue Sprache mehr oder weniger so nebenbei einverleibt, dann sind 2 Jahre sicher eine lange Zeit und das Ergebnis völlig unbefriedigend, aber aus Respekt vor dem Alter wollen wir darauf mal nicht näher eingehen...
Jedenfalls habe ich das, was ich heute anwenden kann zu einem Großteil durch lesen und analysieren von Codebeispielen gelernt. Die Dokumentation gewann erst nach und nach an Bedeutung. Was nützt einem Kind der Dudeneintrag zu 'Eisenbahn'? Erst wenn Mutter oder Vater erklären, dass sie jetzt mit der Eisenbahn in den Zoo fahren, wird es beginnen, dieses Wort einzuordnen um es dann auch selbst verwenden zu können. Und wenn es dann am Bahnsteig steht und durch den Lautsprecher hört, dass der 'Zug' einfährt, wird es lernen müssen, was es wohl damit auf sich hat.
Wenn ich denke, eine Anweisung, eine Funktion oder eine gebräuchliche Herangehensweise an ein Problem verstanden zu haben sehe ich an anderer Leute Code, wie eine Funktion auch noch verwendet werden kann, wie eine Problemlösung viel eleganter oder einfacher zu bewerkstelligen ist. Dass dort, wo ich bisher 'Eisenbahn' verwendet habe, inzwischen mehr und mehr 'Zug' benutzt wird veranlasst mich dann, in der Doku nachzulesen und zu erfahren, dass 'Eisenbahn' inzwischen deprecated ist. Würde ich mein Wissen um 'Eisenbahn' und 'Zug' überwiegend aus Doku und Lehrbuch haben, wäre mein Einsatz dieser Wörter eher steril und uninspiriert.
Ähnliches sehe ich auch bei meinem 11jährigen Sohn. Ob es 'Python for Kids' oder 'Hello World!' waren: Er hält sich nicht sehr lange mit Erklärungen über dies oder jenes auf. Er hat sich von den CD's die Programme kopiert (ja, ich habe ihm auch gesagt, dass Abtippen sinnvoller wäre, ...) und daran herumgebastelt. Erstmal nur Texte ausgewechselt. Dann winzige Erweiterungen erstellt. Und so ist er nebenbei ständig damit beschäftigt, den Code mit dem zu Vergleichen, was letztlich auf dem Bildschirm erscheint.
Klar macht er dadurch vieles anderst (falsch), als es ein gut gemeintes Lehrbuch erklärt. Aber er macht es wenigstens. Wäre er gezwungen, sich erstmal und vorallem mit Grundlagen zu beschäftigen, er würde wohl früher oder später für sich zu dem Schluß kommen, dass das mit dem Programmieren nichts für ihn sei. Und wir alle wissen wie schwer es sein kann, nach so einer Feststellung irgendwann wieder einmal die Kurve zu bekommen.
Mein Fazit: Nicht die Sprache selbst ist es, sondern das Hören. Ein Kind hört ständig Sprache um sich herum. Versteht lange Zeit nicht, was das alles zu bedeuten hat. Und trotzdem lernt es durch Beobachtung und Analyse Stück für Stück, mit dem Gehörten umzugehen bis es selbst beginnen wird, erste Worte und dann Sätze zu sprechen.
Mit einer Programmiersprache verhält es sich IMHO nicht anderst.

mutetella

@lunar: Formale Logik ist Stoff des ersten Semesters des Philosophie-Studiums. Ein Bekannter aus Schulzeiten ackerte dafür die gleichen Skripte über Prädikatenlogik & Co durch wie ich für Informatik.

Ansonsten denke ich auch dass Du mit den DSLs bei LISP ein praktisches Problem angesprochen hast. Programme müssen zu einem gewissen Grad formelhaft und technisch bleiben, wenn man nicht nur eine kleine Elite haben möchte, die noch etwas damit anfangen kann und die Programme von anderen versteht, und noch wichtiger: auch warten und weiterentwickeln kann. Aus Wittgenstein's Grenzen, die durch Worte definiert werden, folgt ja auch, dass man mit selbst erfundenen Worten — das sind DSLs ja im Grunde — anderen Grenzen setzen, ja sie regelrecht aussperren kann.

@BlackJack: Eigentor ... da sieht man, dass ich nicht Philosophie studiere

@mutetella: Die Sprache macht sehr wohl einen Unterschied. Sie definiert Grenzen *was* man überhaupt Denken kann. Ein Gedanke, den man in der Sprache die man kennt, nicht vernünftig Ausdrücken kann, der wird einem nie oder nur sehr unwahrscheinlich kommen. Und wenn dann nur als Ahnung, denn formulieren kann man ihn ja nicht wirklich. Ich habe mit imperativen und hardwarenahen Sprachen angefangen. Reihenfolge: BASIC, Assembler, Pascal, und C. Funktionale und objektorientierte Programmierung sind erst relativ jung hinzugekommen. Aber beides hat meine Art über Problemlösungen nachzudenken deutlich verändert/erweitert. Selbst meine C-Programme sehen anders aus als früher. Und nur mit dem Vokabular und dem Wissen von C wäre ich da wohl nicht hingekommen.

Es gibt keinen Programmierer der sich eine neue Sprache so nebenher einverleibt. Das funktioniert nur wenn die Sprache sehr ähnlich zu einer ist, die er schon kann. Und zwar sowohl was Syntax und Semantik, als auch die idiomatische Verwendung angeht. Nur wenn sich das alles 1:1 aufeinander abbilden lässt, kann man eine Sprache einfach nebenher aufnehmen. An der Stelle ist Peter Norvig's Teach Yourself Programming in Ten Years interessanter Lesestoff.

Allerdings frage ich mich warum pillmuncher das Typsystem von Lisp lobt und das von Python mit einem Grund abschmettert der für Lisp genauso gilt. Die Racket-Leute nennen ihre Sprache "untyped" und der Rest der Welt "dynamisch typisiert"...

Btw: ein Beispiel für eine Sprache die man "nebenher" lernt ist etwa CoffeeScript wenn man von JavaScript kommt

Danke für die hochinteressanten Antworten. Die Schüler der 7. Klasse lernen bei uns alle verpflichtend Robot Karol. Der Programmierkurs soll sich an interessierte Schüler ab der 7. Klasse richten, die eine gewisse Begabung oder Interesse fürs Programmieren zeigen.

Leonidas hat geschrieben:Allerdings frage ich mich warum pillmuncher das Typsystem von Lisp lobt und das von Python mit einem Grund abschmettert der für Lisp genauso gilt.

Da hatte ich mich missverständlich ausgedrückt. Ich meinte nicht, Pythons Typ-System sei kaputt, weil Variablen untypisiert sind, sondern es sei deswegen viel weniger kaputt, als zB. das von Java. Guido hat da ziemlich viel ziemlich richtig gemacht. Mal ganz informell: ein Typ-System ist IMO desto kaputter, je mehr es mir im Weg steht beim Programmieren, und das von Python tut das praktisch nie. Python hat schon ein paar Macken, die ich gerne korrigiert sehen würde, etwa das GIL, oder die fehlenden Tail Calls. Das Typ-System jedoch gehört nicht dazu.

Gruß,
Mick.

pillmuncher hat geschrieben:Python hat schon ein paar Macken, die ich gerne korrigiert sehen würde, etwa das GIL, oder die fehlenden Tail Calls.

Das sind allerdings keine Probleme der Sprache, sondern des Standardinterpreters.

stem hat geschrieben:Der Programmierkurs soll sich an interessierte Schüler ab der 7. Klasse richten, die eine gewisse Begabung oder Interesse fürs Programmieren zeigen.

Na dann ist der "technische Overhead" imho zu verkraften und zumutbar. Schließlich sollen sie dann ja wohl über die Grenzen der Spielsprache hinausblicken.

@pillmuncher: Man kann endrekursive Aufrufe in Python nicht so einfach optimieren. In Python kann jeder Namen zu jedem beliebigen Zeitpunkt neu gebunden werden. Es ist folglich nicht garantiert, dass das ein gegenwärtig ausgeführtes Funktionsobjekt beim rekursiven Abstieg noch an denselben Namen gebunden ist.

BlackJack hat geschrieben:Die Sprache macht sehr wohl einen Unterschied. Sie definiert Grenzen *was* man überhaupt Denken kann.

Das bezweifel ich ja auch nicht. Die Wahl der Sprache ist sicherlich auch zu einem großen Teil davon beeinflusst, welche Anwendung man entwickeln möchte. Für meinen Kalender und den Umstand, dass ich meinen Code nicht 'blickdicht' machen muss, eignet sich Python hervorragend. Für Egosoft wird sich für das neue 'X-Rebirth' (das hoffentlich bald erscheinen wird *hufscharren*) sicherlich für eine andere Sprache entschieden haben.
Andererseits wurde ja auch die eine oder andere Sprache entwickelt, weil es für bestimmte Anwendungsfälle keine brauchbare Sprache gab.
Ob es aber, abgesehen von Sprachen wie Brainfuck o. ä., so entscheidend ist, mit welcher Sprache ein Kind/Jugendlicher zu programmieren beginnt?

Zudem wollte ich mit meinem Beitrag auch unterstreichen, dass ich es neben dem reinen Vermitteln von Wissen mindestens genauso wichtig halte, Code zu analysieren und herauszuarbeiten, wo was wie geschieht. Selbst wenn die Sprache selbst nur teilweise beherrscht wird. Ich glaube, dass es kaum eine bessere Möglichkeit gibt, ein Gefühl für eine Sprache zu bekommen, als von Anfang an so viel wie möglich Codesnippets zu lesen.

mutetella

@mutetella: Wahrscheinlich wird Egosoft nicht eine wirklich deutlich andere Sprache als Python verwenden. Es wird sich wahrscheinlich im gleichen ”Kulturkreis” bewegen. Imperative Sprache mit OOP-Unterstützung. Aber schau Dir zum Beispiel mal funktionale Sprachen an, wie Haskell oder auch die Klassiker Scheme oder Lisp. Ich hatte BASIC, Assembler, Pascal, und C hinter mir als ich das Informatikstudium anfing und bin da mit dem Selbstbewusstsein rein gegangen, dass ich programmieren kann. Und dann haben wir im ersten Semester mit Programmieren in Haskell angefangen — und das hat mich ziemlich hart auf 0 zurück gesetzt! All das Wissen was ich hatte, war sogar eher hinderlich, weil ich erst einmal alles mögliche bisher Gelernte aktiv vergessen und verdrängen musste, um überhaupt aufnahmefähig für diese Art des Denkens und Formulierens von Lösungen zu werden. Umgekehrt habe ich Leute gesehen die mit Haskell den ersten Kontakt mit Programmieren hatten und da recht leicht hinein gefunden haben, dafür dann aber im nächsten Semester massive Probleme mit imperativer OO-Programmierung hatten. Da mussten *die* dann erst einmal umdenken.

Bei dermassen unterschiedlichen Ansätzen kann es IMHO nicht egal sein womit man anfängt. Ich kann allerdings auch nicht sagen wie und womit man anfangen sollte. Soweit ich das beurteilen kann, ist das recht individuell womit der einzelne mehr anfangen kann — was seinen Denkmustern am ehesten entspricht.

Ich finde auch bis zu einem gewissen Grade wichtig, zu verstehen, warum jemand eine neue Sprache geschaffen hat, also warum es zu dieser neuen Sprache überhaupt gekommen ist.
Dennis Ritchie wollte 1971 Systembefehle für Unix schreiben, Assembler war ihm zu "low-level", daher entwickelte er C.
Larry Wall wollte 1986 mit C Textdateien verarbeiten, doch es stellte sich heraus, daß das für ihn als Programmierer damit viel zu umständlich war. Also schrieb er - in C - Perl.
So, an dieser Stelle bin ich nicht 100%ig sicher: Guido van Rossum könnte sich um 1990 Perl angesehen haben, das eigentlich ganz gut gefunden haben, doch den Code furchtbar unleserlich und, gerade bei größeren Programmen, kaum noch zu verstehen. "Magische Variablen" wie "$_" usw. sowie die eigenartige OOP-Implementierung könnten weitere Kritikpunkte gewesen sein. Deshalb könnte er eine neue Sprache entwickelt haben, die diese Nachteile vermieden hätte, also eine Art "sauberes Perl", wiederum geschrieben in C, also CPython.
Wenn Schüler an Python herangeführt werden, ohne etwas von dieser Entwicklung zu erfahren, fehlt ihnen meiner Meinung nach ein wichtiger Schlüssel zum Verständnis, warum etwas in Python gerade auf eine bestimmte Weise gemacht wird. Zum Beispiel, warum sie in ein relativ enges Syntax-Korsett gezwungen werden, und die Ausdrucksmittel im Verhältnis zu Perls

Larry Wall hat geschrieben:There's more than one way to do it.

(absichtlich) stark eingeschränkt sind.

@BlackJack:
Ok, obwohl ich die Unterschiede der einzelnen Sprachen nicht kenne, verstehe ich schon, worauf Du hinaus willst...
Wenn man das weiterspinnt kommt die Frage auf, ob es für Chinesen wohl geeignetere Sprachen zum Programmiereinstieg als für jemanden aus unserem Kulturkreis gibt.
Und ob Menschen, die sich mit Haskell am wohlsten fühlen zu einem anderen Typ gehören, als diejenigen, die lieber mit Python arbeiten.
Aber wie so oft wird es wohl auf das hinauslaufen, was Du bereits gesagt hast: Es kommt ganz darauf an.

mutetella

@problembär: Das ist reichlich viel Spekulation über die Entstehung von Python. Python ist nicht als Antwort oder Gegenspieler von Perl entstanden. Guido brauchte eine allgemein verwendbare Programmiersprache zwischen C und Shell-Skripten für das Amoeba-Betriebssystem und hat sich grundsätzlich erst einmal von der Programmiersprache ABC inspirieren lassen. Diese kannte er aus dem Studium, denn sie wurde an der Uni entwickelt wo er studierte, und später dann auch anfing Python zu entwickeln. ABC ist eine unter anderem für die Lehre entwickelte Sprache zu der es auch ein paar Untersuchungen in diese Richtung gibt. Deshalb haben wir zum Beispiel den Doppelpunkt vor eingerückten Blöcken in der Syntax, obwohl die Sprache technisch auch ohne ihn auskäme. Ich bezweifle aber, dass die Schüler jetzt unbedingt das Amoeba-Betriebssystem oder die ABC-Sprache kennen lernen müssen um Python zu verstehen. Ich wage mal zu behaupten die überwiegende Mehrzahl der Pythonistas kennt beides aller höchstens vom Namen nach.

Die Entwurfsphilosophie bei der Syntax ist auf Lesbarkeit ausgelegt. Das kann man Lernenden aber auch sagen, ohne das man sie vorher mit einer weniger auf Lesbarkeit ausgelegten Sprache erschrecken muss.

Hallo,

welches Programmierparadigma für Einsteiger am besten ist, ist IMHO schwer zu sagen. In so fern finde ich Python schon ganz ok, weil es sich ja da recht flexible gibt bzw. man kommt auch (erstmal) ohne OO Programme schrieben. Und, wenn auch nicht sooo prall, mal ein bisschen funktionale Programmierung machen.

Wobei für funktionale Programmierung ein bisschen (mehr) Mathewissen IMHO nicht schlecht ist...

BTW, um mal auf BlackJacks Erfahrung aus dem 1. Semster zurück zu kommen: ich habe letzthin das Buch "Seven Languages in Seven Weeks" gelesen (super Buch!). Da ging es mir bei Prolog ähnlich: Nach der Hälfte des Kapitels musst ich erst mal geistig aussteigen, weil diese Logik-basierte völlig anders war als alles, was ich so kannte.

So, die Ausgangsfrage des OP war aber, ob jemand Vorschläge für Aufgaben für eine Python-Kurs hat. Außer "Poker" kam da bis jetzt glaube ich nicht viel.

Gruß, noisefloor

noisefloor hat geschrieben:So, die Ausgangsfrage des OP war aber, ob jemand Vorschläge für Aufgaben für eine Python-Kurs hat. Außer "Poker" kam da bis jetzt glaube ich nicht viel.

Vielleicht liegt das daran, dass die Fragestellung nicht zu dem passt, was er vorhat.
Wie er mittlerweile verraten hat, handelt es sich um Schüler, die bislang nur mit einer speziellen Programmierlernumgebung (Karol) in Kontakt gekommen sind und nun mittels Python in die Grundlagen der Programmierung eingeführt werden sollen. Dazu braucht man in erster Linie nicht einfach Aufgaben, sondern zunächst einmal ein Grundkonzept, wie man dies tun will. Die Aufgaben kommen dann (fast) von alleine.

Möglichkeiten wären z.B. der klassische Weg:
- Der interaktive Interpreter als Taschenrechner (int, float, Operatoren für Zahlen; Variablen)
- Ein- und Ausgabe inkl. Typumwandlung (str -> int/float)
- Kontrollstrukturen (bedingte Anweisungen, Schleifen)
- eigene Funktionen
- weitere Datenstrukturen (str, list, tuple, dict)
- sequentielle Dateien
Damit ist man schon einige Wochen beschäftigt. Die Aufgaben sind dann jeweils sehr begrenzt und an die jeweils neu erarbeiteten Inhalte angepasst (z.B. ein Programm, das vom Anwender zwei Zahlen erwartet, eine selbst entwickelte Funktion enthält, die die größere der beiden Zahlen zurückliefert und diese Funktion verwendet, um den Anwender darüber zu informieren.).
Wer in der Lage ist, für sich bzw. seine Zielgruppe ein entsprechendes Grundgerüst der Vermittlung zu entwickeln, sollte dann auch keine Schwierigkeiten haben, dazu passende Aufgaben stellen zu können.

Eine Alternative zu diesem klassischen Weg habe ich in einem früheren Post schon genannt: "Python für Kids". Ein Zugang, der über das (x)turtle-Modul in die Programmierung mit Python einführt.

lunar hat geschrieben:@pillmuncher: Da diejenigen, die nicht Informatik oder Mathematik studieren, später eigentlich nur rechnen müssen, legt das Gymnasium folglich auch nur die Grundlagen zum Rechnen, im Bezug auf Funktionen eben Differential- und Integralrechnung. Philosophie- oder Chemie-Studenten, ja nicht einmal Programmierer, brauchen zum Leben und Arbeiten nun mal weder formale Logik noch eine genaue Vorstellung vom Funktionsbegriff ...

Als Programmierer braucht man, meine ich, die Fähigkeit, logisch schließen zu können. Eigentlich sollte man das in der Schule trainieren, und es sollte IMO zur allg. Hochschulreife gehören. Rechnen lernt man, indem man es immer und immer wieder trainiert. Warum macht man das nicht auch bei der Logik? Wo man doch in der Logik ebenso rechnen kann? Ein Beispiel:

Was ist das Gegenteil von "wenn es regnet, dann ist die Straße nass" = ~(p -> q)?
a) "wenn es NICHT regnet, dann ist die Straße nass" = (~p -> q)
b) "wenn es regnet, dann ist die Straße NICHT nass" = (p -> ~q)
c) "wenn es NICHT regnet, dann ist die Straße NICHT nass" = (~p -> ~q)
d) was anderes.

Die richtige Antwort ist d): Zurückübersetzt in normales Deutsch: "Es regnet, aber die Straße ist nicht nass".

Das Rechenverfahren stammt von Van "The Man" Quine und ist recht einfach. Man schreibt die zu testende Formel auf und setzt darunter auf der linken Seite für irgendeine Variable durchgehend T ein und auf der rechten Seite für dieselbe Variable durchgehend F. Dann vereinfacht man:

1. ~~x wird zu x.
2. ~T wird zu F.
3. ~F wird zu T.
4. T & x oder x & T wird zu x.
5. F & x oder x & F wird zu F.
6. T v x oder x v T wird zu T.
7. F v x oder x v F wird zu x.
8. T -> x wird zu x.
9. F -> x wird zu T.
10. x -> T wird zu T.
11. x -> F wird zu ~x.
12. x == x wird zu T.
13. Alles andere wird zu F.

Bei mehr als zwei Variablen macht man ggf. neue Unter-Spalten auf und wendet das Verfahren rekursiv an. Genauso wie beim arithmetischen Rechnen kann man abkürzen und muss nicht für jeden Schritt eine eigene Zeile aufmachen. Am Schluss jedes Blocks kommt immer T oder F raus. Wenn bei allen Blocks T rauskommt ist das Ergebnis T, sonst F. Wenn man den Punkt 13 abändert, lässt sich nicht nur Allgemeingültigkeit feststellen, sondern auch Erfüllbarkeit und Unerfüllbarkeit. Die Einzelheiten sind nicht so wichtig. Das logische Rechnen sollte für Abiturienten nicht zu schwierig sein, und für Hochschüler auch nicht. Der Nutzen liegt einerseits in der Anwendbarkeit des Verfahrens selbst und andererseits in der Schulung des logischen Denkens.


Philosophen und Logik: Quine war Philosoph. Sein Schüler Donald Davidson hat den Davidson'schen Slingshot erfunden. Dazu eine kurze Vorgeschichte:

Die Philsophen fragen sich seit jeher aus was die Welt besteht. Die vorsokratischen Philosophen schlugen ua. Die Vier Elemente vor, und stritten darüber, ob und wie man die verschiedenen Elemente aufeinander zurückühren konnte. Die Erfahrung der Griechen war, dass Wasser zu Eis werden konnte, und umgekehrt, weswegen sie glaubten es handle sich dabei um unterschiedliche Substanzen (feste und flüssige), die wechselweise ineinander überführt werden konnten. Das war übrigens keine Philosophische Theorie, sondern Allgemeinwissen. Die damaligen Philosophen arbeiteten mit den alltäglichen Überzeugungen ihrer Zeitgenossen, so wie die heutigen das auch tun. Der erste Philosoph, der systematisch die Alltagsweisheit als inadäquat ansah und sie deswegen permanent angriff, war Sokrates. Bei dessen Schüler Platon wandelte sich die Substanz-Diskussion ua. dahingehend, dass er Grade der Existenz zu sehen glaubte, und das aller-realste, und mithin substantiell reinste, in den abstrakten Ideen. Seinem Schüler Aristoteles, der Details liebte und ein großer Systematiker war, war das wohl etwas zu mystisch. Er gliederte die Modi des Seins entlang der griechisch/indogermanischen Grammatik und systematisierte so erstmals die Logik und die Linguistik. Die Verwandschaft ist heute noch sichtbar, wenn sowohl Philosophen als auch Linguisten Logik lernen müssen. Im scholastischen Mittelalter kam durch den Rückgriff auf Aristoteles der Substanz-Begriff wieder in die Diskussion, und zwar im Rahmen des Nominalismus-Streits, den IMO Occam gewonnen hat. Die dabei gewonnene Perspektive auf das Problem überlebte die anti-scholastische Revolution durch Descartes und so wurde die Substanz-Diskussion in der Neuzeitlichen Philosophie wiederbelebt. Hegel meinte, die grundlegendste Substanz sei die Vernunft selbst. Marx meinte, die Materie. Schopenhauer, der Wille. Wittgenstein, die Satzartigkeit. Was soll das sein? Nun, Wittgenstein wollte die durch Frege und Peirce erfundene Prädikatenlogik zur Fundamental-Philosophie modeln und postulierte deswegen, die basalen Elemente der Wirklichkeit seien den basalen Elementen der Logik isomorph. In der Logik ist die kleinste unabhängige Einheit der Satz. Worte haben nur in Sätzen Bedeutung (Frege-Prinzip), und analog sollten Dinge nur in Tatsachen vorkommen können. Wittgestein postuliert also im Tractatus Logico-Philosophicus: Die Welt zerfällt in Tatsachen, womit er meint, die Welt bestehe in ihren kleinsten unabhängigen Einheiten aus Tatsachen. "Der Hund bellt", "Die Katze sitzt auf der Matte", "Angela Merkel ist Bundeskanzlerin", usw. sind Sätze, denen, damit sie wahr sind, etwas in der Welt korrespondieren muss, nämlich die Tatsachen, die sie ausdrücken.

Die Frage ist nun, hat W. recht? Gibt es Tatsachen wirklich, und wenn ja, sind sie der Wirklichkeit kleinste Einheiten und den Sätzen isomorph? Ich kenne Hunde, auch solche die bellen, aber ein satzartiges Ding, das Bestandteil der Welt ist und isomorph zum Satz "der Hund bellt" ...? Um wahr zu sein, müsste diese Theorie mindestens das liefern, dass für jeden Satz 'p' gilt:

(a) Der Satz 'p' stimmt mit der Tatsache überein, dass p.

Ich rekonstruiere jetzt mal Davidsons Argument:

(b) Der Satz, dass München in Bayern liegt, stimmt mit der Tatsache überein, dass München in Bayern liegt.

(c) Der Satz, dass München in Bayern liegt, stimmt mit der Tatsache überein, dass (der x derart, dass x == Diogenes, und München in Bayern liegt) == (der x derart, dass x == Diogenes).

(d) Der Satz, dass München in Bayern liegt, stimmt mit der Tatsache überein, dass (der x derart, dass x == Diogenes, und Frankfurt in Hessen liegt) == (der x derart, dass x == Diogenes).

(e) Der Satz, dass München in Bayern liegt, stimmt mit der Tatsache überein, dass Frankfurt in Hessen liegt.

Die Ersetzungen folgen dabei diesen formal-logischen Gesetzen:wobei (x) der Allquantor ist und (ix) der jota-Operator, also "der/die/das x derart, dass ...".

Die Annahme, dass wahren Sätzen Tatsachen entsprechen, führt also offenbar zu der grotesken Konsequenz, dass jedem wahren Satz alle Tatsachen entsprechen. Wenn man aber sprachlich die einzelnen Tatsachen nicht mehr unterscheiden kann, dann braucht man auch nicht anzunehmen, dass sie sich überhaupt unterscheiden. Somit genügt es, eine einzige Tatsache anzunehmen, die alle Sätze wahr macht, nennen wir sie DIE GROSSE TATSACHE. Dann brauchen wir aber (a) nicht mehr und können statt dessen schreiben:

(f) Der Satz, dass p, stimmt mit DER GROSSEN TATSACHE überein.

Für 'p' dürfen wir jeden Satz einsetzen, sofern er nur wahr ist.

Damit ist die Theorie Wittgensteins, dass die Welt in Tatsachen zerfällt, ad absurdum geführt. Damit ist natürlich nicht bewiesen, dass es keine Tatsachen gibt und statt dessen alles Einbildung ist. Nur eben die Möglichkeit der Konstruktion Satz <=> Tatsache ist ausgeschaltet. Mit solcherlei Überlegungen ist man als Philosoph beschäftigt, und ohne Logik ist man dabei verloren. Interessant an dieser Geschichte ist übrigens, dass der Tractatus Logico-Philosophicus soz. die Gründungsschrift der Analytischen Philosophie ist, deren Vertreter Davidson war. Und Wittgenstein hatte diese Position längst aufgegeben als Davidson das Slingshot-Argument brachte, er lebte sogar nicht mal mehr. Es richtete sich also letztlich nicht gegen Wittgenstein, sondern gegen diejenigen, die an Wittgensteins Früh-Philosophie kleben geblieben waren.

lunar hat geschrieben:LISP ist auch nicht perfekt, unter anderem auch deswegen, weil sich damit wirklich jeder seine eigene DSL für sein Problem zimmert, und dabei soweit abstrahiert, dass die Lösung hinter all der Abstraktion oft genug überhaupt nicht mehr zu erkennen ist. In Python oder Haskell käme niemand auf die Idee, die Fakultät über Church-Numerale zu implementieren, weil damit so schick von konkreten Zahlen abstrahieren kann, und nur noch Funktionen braucht. In LISP aber scheint derlei geradezu Qualitätsmerkmal eines guten Programmierers zu sein, mit dem Resultat, dass es oftmals unmöglich ist, fremde Programme unmittelbar zu verstehen.

Zuletzt hatte ich eine BoundingBox Klasse geschrieben, mit der man zB. sowas machen konnte:Weil $Kollege die aber nicht hernehmen wollte, sah das bei ihm dann in etwa so aus:Natürlich war das nur eine von vielen Stellen im Code, wo bounding boxes aufgespannt wurden, und es sah überall so aus. Nur schlimmer. Das verstößt eklatant gegen DRY. Aber $Kollege liebt top down Entwurf und ist großer MDA Fan. Big Design Upfront. Kleine Tools die einem das Leben leichter machen, wie eine BoundingBox Klasse, die einfache Tests für Überschneidung und einfache Operationen zum Aufspannen etc. mitbringen, sind ihm völlig fremd, weil das ja nicht von oben nach unten entworfen wurde. Ist jedenfalls meine Interpretation seines Verhaltens.

Dagegen nehme ich den LISPer jederzeit.

lunar hat geschrieben:@pillmuncher: Man kann endrekursive Aufrufe in Python nicht so einfach optimieren. In Python kann jeder Namen zu jedem beliebigen Zeitpunkt neu gebunden werden. Es ist folglich nicht garantiert, dass das ein gegenwärtig ausgeführtes Funktionsobjekt beim rekursiven Abstieg noch an denselben Namen gebunden ist.

Dieses Problem betrifft aber den expliziten rekursiven Aufruf genauso. Mir geht es übrigens weniger um Endrekursion, als um Continuations als flexible Kontroll-Struktur. Die funktionieren letztlich nur mit tail calls, oder mit unendlich großem call stack.

Gruß,
Mick.

Um zum Thema wenigstens was randstängiges beizutragen: Coding Horror: Separating Programming Sheep from Non-Programming Goats. Ich glaube nicht daran, dass alles angeboren ist. Deshalb weiß ich nicht recht, was ich davon halten soll. Aber vielleicht hilft es ja dem OP.

Mir gefiel das hier:

Formal logical proofs, and therefore programs – formal logical proofs that particular computations are possible, expressed in a formal system called a programming language – are utterly meaningless. To write a computer program you have to come to terms with this, to accept that whatever you might want the program to mean, the machine will blindly follow its meaningless rules and come to some meaningless conclusion. In the test the consistent group showed a pre-acceptance of this fact: they are capable of seeing mathematical calculation problems in terms of rules, and can follow those rules wheresoever they may lead. The inconsistent group, on the other hand, looks for meaning where it is not. The blank group knows that it is looking at meaninglessness, and refuses to deal with it.

Formale logische Beweise, und daher Programme - formal-logische Beweise, dass bestimmte Berechnungen möglich sind, ausgedrückt durch ein formales System genannt Programmiersprache - sind völlig bedeutungslos. Um ein Computer-Programm zu schreiben muss man das hinnehmen, man muss akzeptieren, was auch immer man sich wünscht, dass ein Programm bedeutet, dass die Maschine blindlings ihren bedeutungslosen Regeln folgen und zu irgendeiner bedeutungslosen Schlussfolgerung gelangen wird. Im Test zeigten die Mitglieder der konsistenten Gruppe, dass sie diese Tatsache von vorneherein akzeptierten: sie sind in der Lage, mathematische Berechnungsprobleme im Hinblick auf deren Regeln zu betrachten und können diesen Regeln folgen, wo immer sie sie auch hinführen mögen. Die Mitglieder der inkonsistenten Gruppe andererseits suchen Bedeutung wo keine ist. Die Mitglieder der Gruppe, die die Fragen unbeantwortet gelassen hat, weiß, dass sie auf auf Bedeutungslosigkeit blickt und weigert sich, sich darauf einzulassen. (meine - etwas freie - Übersetzung)

Wie Hilbert schon sagte: "Man muß jederzeit an Stelle von 'Punkte, Gerade, Ebenen' 'Tische, Bänke, Bierseidel' sagen können".

@pillmuncher: Um das Verhalten Deines Kollegen geht es nicht. Mit Top-Down vs. Bottom-Up hat es wenig zu tun, es mangelt ihm offensichtlich einfach nur an Einsicht, ich gehe nicht davon aus, dass er ein guter Programmierer ist.

Gute Python-Programmierer schreiben in Python im Rahmen der Sprache idiomatischen Python-Quelltext, den jeder andere gute Programmierer zumindest verstehen kann, auch wenn er selbst vielleicht einzelne Teile anders implementieren würde. LISP-Programmierer dagegen schreiben Quelltext, denn selbst andere gute LISP-Programmierer nicht mehr so weiteres verstehen, eben weil es gar nicht mehr LISP selbst ist, sondern eine ganz andere Sprache, nämlich die DSL, welche der Programmierer sich für sein Problem gezimmert hat.

Den Rest Deines Beitrags habe ich nur überflogen, weil er mir ehrlich gesagt zu weitscheifend war. Mag ja sein, dass formale Logik essentieller Bestandteil der philosophischen Kulturgeschichte, im praktischen Leben ist formale Logik kaum je von Nutzen. Niemand trifft Entscheidungen, indem er sie formal aus Fakten inferiert.

Die meisten Menschen denken einfach nur nach, wenden mithin intuitive Logik an. Das muss die Schule nicht vermitteln, das können Menschen auch so (nun ja, nicht alle, aber das sei dahingestellt).