Gesucht: Python-Aufgaben für Schul-Programmierkurs

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
mutetella
User
Beiträge: 1695
Registriert: Donnerstag 5. März 2009, 17:10
Kontaktdaten:

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
Entspanne dich und wisse, dass es Zeit für alles gibt. (YogiTea Teebeutel Weisheit ;-) )
BlackJack

@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.
problembär

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.
mutetella
User
Beiträge: 1695
Registriert: Donnerstag 5. März 2009, 17:10
Kontaktdaten:

@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
Entspanne dich und wisse, dass es Zeit für alles gibt. (YogiTea Teebeutel Weisheit ;-) )
BlackJack

@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. ;-)
Benutzeravatar
noisefloor
User
Beiträge: 3856
Registriert: Mittwoch 17. Oktober 2007, 21:40
Wohnort: WW
Kontaktdaten:

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
Benutzeravatar
numerix
User
Beiträge: 2696
Registriert: Montag 11. Juni 2007, 15:09

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.
Benutzeravatar
pillmuncher
User
Beiträge: 1484
Registriert: Samstag 21. März 2009, 22:59
Wohnort: Pfaffenwinkel

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

Code: Alles auswählen

a)            ~(p -> q) == (~p -> q)
~(T -> q) == (~T -> q)  |  ~(F -> q) == (~F -> q)
       ~q == T          |         ~T == q
          F             |            F
                        F

b)            ~(p -> q) == (p -> ~q)
~(T -> q) == (T -> ~q)  |  ~(F -> q) == (F -> ~q)
       ~q == ~q         |         ~T == T
          T             |            F
                        F

c)            ~(p -> q) == (~p -> ~q)
~(T -> q) == (~T -> ~q) |  ~(F -> q) == (~F -> ~q)
       ~q == T          |         ~T == ~q
          F             |            F
                        F

d)            ~(p -> q) == (p & ~q)
~(T -> q) == (T & ~q)   |  ~(F -> q) == (F & ~q)
       ~q == ~q         |         ~T == F
          T             |            T
                        T
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:

Code: Alles auswählen

(x)(fx) & p ==> (x)(fx & p)
(x)(fx & p) ==> (x)(fx)
(ix)(fx) & p ==> (ix)(fx & p)
(ix)(fx & p) ==> (ix)(fx)
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:

Code: Alles auswählen

boxes = []
for x, y in some_points():
    rect = x, y, x + n, y + m
    for box in boxes:
        if box.overlaps(rect):
            box.enclose(rect)
            break
    else:
        boxes.append(BoundingBox(rect))
Weil $Kollege die aber nicht hernehmen wollte, sah das bei ihm dann in etwa so aus:

Code: Alles auswählen

boxes = []
for x, y in some_points():
    rect = x, y, x + n, y + m
    for box in boxes:
        if not ( box[0] > rect[2] or box[2] < rect[0] or box[1] > rect[3] or box[3] < rect[1] ):
            box[0] = min(box[0], rect[0])
            box[1] = min(box[1], rect[1])
            box[2] = max(box[2], rect[2])
            box[3] = max(box[3], rect[3])
            break
    else:
        boxes.append(rect)
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.
In specifications, Murphy's Law supersedes Ohm's.
Benutzeravatar
pillmuncher
User
Beiträge: 1484
Registriert: Samstag 21. März 2009, 22:59
Wohnort: Pfaffenwinkel

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".
In specifications, Murphy's Law supersedes Ohm's.
lunar

@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).
lordnaikon
User
Beiträge: 58
Registriert: Dienstag 9. Februar 2010, 13:41

lunar hat geschrieben: 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).
Das ist aber allenfalls sehr traurig! Hier muss ich widersprechen, genau das sollte auch in der Schule gelehrt werden, wenn wir nicht wollen, dass Schulabgänger nur "Arbeitswerkzeuge" sind - nur ausgestattet um in der Arbeitswelt zu bestehen. Wie kann man in solch einem Fall noch von einem mündigen Bürger, der die Schule verlässt, sprechen? Hier muss ich pillmuncher recht geben, Logik ist in vielen Fällen einfach nicht intuitiv genug. Große Denker sind schon daran gescheitert, weil sie sich einfach intuitiv was zusammengezimmert haben und nicht die Werkzeuge hatten ihr Erdachtes zu überprüfen. Es war halt intuitiv logisch. Darum müssen wir lernen sie zu verstehen, genau weil wir sie zu wenig anwenden! Sprechen muss ich formal nicht lernen, weil ich es "aufschnappe" - es alle paar Minuten verwende. Richtiges logisches Denken machen die wenigsten (traurig aber wahr). Wo sonst als in der Schule hätten wir die Möglichkeit so etwas richtig zu lernen? Ich bin für Logik in der Schule! Ich bin zwar auch nicht der hellste, mich ärgert es aber manches mal bei Diskussionen jemandem erklären zu müssen, warum seine Argumente "nicht logisch" sind. Hätten die Leute in der Schule Logik gehabt, hätten sich vielleicht mehr Leute gefragt, welcher logischen Zusammenhang zwischen "Websprerren" und "Schutz der Kinder vor Missbrauch" besteht. Wenn das logische Schließen öfter geübt und verinnerlicht werden würde, würden sich vielleicht mehr Menschen über Sachen wie die "Beitragsermessungsgrenze" wundern; oder warum wir immer die "wahnwitzig" schnell "tickende" Schuldenuhr präsentiert bekommen, mit dem "logischen Schluss" wir müssen sparen, sparen, sparen. In jeder Unternehmens Bilanz gibt es sowas wie Aktiva und Passiva. Bei uns scheint das aber scheinbar "niemand" zu tun und verpasst das noch "wahnwitzigererere" emporschnellen der Privatvermögen. Niemand "schließt" mal das die "Schulden" letztendlich in den Vermögen landen.

Sry wegen dem harten Offtopic.

Um vielleicht doch noch was zum Thema beizutragen: Wie sieht es denn mit einer Evaluierung der "Betroffenen" aus? Wie ist der Wissenstand der Jugendlichen - auch im Hinblick auf HTML, Javascript wäre super ... usw. Was wollen sie selber im Kurs machen?
lunar

@lordnaikon: Du übertreibst und Du redest Unsinn. Es geht nicht um logisches Denken im Allgemeinen, sondern ganz speziell um formale Logik. Lies vielleicht nochmal die Beiträge von pillmuncher, und dann versuche dann mal, den von Dir behaupteten logischen Zusammenhang zwischen der Lehre formaler Logik und Kindesmissbrauch bzw. Staatsschulden so richtig formal zu beweisen. Ich hoffe, Du erkennst dann selbst, wie unsinnig Deine „Argumente“ sind, und dass Du selbst getan hast, was Du eigentlich kritisiert: Unlogische Argumente so zusammen zu zimmern, dass sie zu Deiner (vorher schon gefassten) Meinung passen.
lordnaikon
User
Beiträge: 58
Registriert: Dienstag 9. Februar 2010, 13:41

@lunar: Ich finde meinen Unsinn gar nicht so übertrieben. Überspitzt, Ok - unverständlich, vielleicht auch. Was ich eigentlich nur sagen wollte ist: Man bekommt ein "besseres" Gefühl für logisches Denken im Allgemeinen, was du ja außen vor lässt. Ich weiß es gibt einen Formalismus. Ich weiß meine Intuition kann sehr schnell sehr falsch sein. Mir ging es auch nicht darum aufzuzeigen wie super ich Kindesmissbrauch herleiten kann o.Ä. Es ging darum die "Sinne" zu schärfen und bekanntes aus der formalen Logik auch für das Leben zu verwenden um zu erkennen wo logische Fehler sind, beispielsweise in der Argumentation von Leuten. "Die Straße ist nass, also spannt den Regenschirm auf denn es Regnet! Ihr habt keinen, dann kauft einen. Ihr könnt euch keinen Leisten? Dann müsst ihr sparen, sparen. sparen!"

So meinte ich das.
Benutzeravatar
pillmuncher
User
Beiträge: 1484
Registriert: Samstag 21. März 2009, 22:59
Wohnort: Pfaffenwinkel

lunar hat geschrieben:@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 denke schon, dass es einen Zusammenhang zwischen der Vorliebe für Top-Down-Entwurf und dieser Art zu Programmieren gibt. Wenn man ein System von oben nach unten entwirft, wird man zwangsläufig irgendwo in der Mitte haltmachen müssen, weil sich sonst die Komplexität des Entwurfs der des fertigen Programms annähern würde. Man bestimmt also beim Entwurf mehr oder weniger willkürlich eine unterste Abstraktions-Stufe und beginnt zu programmieren. Programmierer des von mir kritisierten Typs neigen dazu, alles unterhalb dieser untersten Entwurfs-Ebene als flach anzusehen (weil sonst wäre es ja schon beim Entwurf als nicht-flach gekennzeichnet worden). Folglich programmieren sie auch flach, ohne Abstraktion/Generalisierung der Konstrukte der Programmiersprache, also alles mittels if-Statements, Zustands-Variablen, Index-Zugriffen auf Listen, etc.. Beim Bottom-Up-Entwurf (AKA wir bauen uns Libs und interne DSLs) dagegen schichtet man so lange Abstraktions-Ebenen aufeinander, bis das Programm trivial zu implementieren wird. Wie Paul Graham schreibt: "[...] bottom-up design doesn't mean just writing the same program in a different order. When you work bottom-up, you usually end up with a different program. Instead of a single, monolithic program, you will get a larger language with more abstract operators, and a smaller program written in it."

'a smaller program' bedeutet uaa.: weniger komplex, einfacher zu implementieren, und vor allem: weniger Bugs, weil die Anzahl der Bugs in Programmen korreliert ist mit deren SLOC, wie Les Hatton in diesem PDF schreibt.
lunar hat geschrieben: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.
Vielleicht suchen LISPer einfach nach ultimativer mathematischer Eleganz, wohingegen Pythonistas glauben: readability counts, und practicality beats purity.

[EDIT]
lunar hat geschrieben: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.
Es gibt kein spezielles Wissen oder Können, das nur Philosophen zugänglich wäre. Philosophen versuchen einfach, sich systematisch dumm zu stellen, um dann die dummen Fragen unter Aufbringung jedes geeignet erscheinenden Mittels zu beantworten. Die formale Logik verwenden Philosophen dabei nicht wegen ihrer Formalität, sondern weil sie hoffen, durch größere Klarheit über die Fragestellung differenziertere und zutreffendere Antworten zu gewinnen. Die Möglichkeit, größere Klarheit über Probleme und bessere Lösungen für sie zu finden, ist etwas, das man in Beruf und Alltag genauso brauchen kann.
[/EDIT]

lunar hat geschrieben: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).
Ich gebe gerne zu, dass die wenigsten ihre Entscheidungen unter Rückgriff auf formale Methoden treffen. Aber ich frage mich, ob die Erde nicht ein besserer Ort wäre, wenn mehr Menschen es tun würden.

Und was formale Logik und Programmieren angeht, verweise ich auf Coding Horror: Separating Programming Sheep from Non-Programming Goats. Bedeutungslosen Regeln zu folgen oder sie im Rahmen eines Programms aufzustellen fällt ungemein leichter, wenn man ein geeignetes Werkzeug besitzt. Die formale Logik ist so ein Werkzeug. Und sie ist ja nicht mal schwer zu verstehen, da, wie du zurecht sagst, jeder schon ein intuitives Vorverständnis mitbringt. Ich bin eben der Meinung, man sollte dieses Vorverständnis zu einem richtigen Verständnis ausbauen, und die Schule wäre IMO der geeignete Ort dafür.
Zuletzt geändert von pillmuncher am Sonntag 12. Juni 2011, 17:36, insgesamt 1-mal geändert.
In specifications, Murphy's Law supersedes Ohm's.
Benutzeravatar
pillmuncher
User
Beiträge: 1484
Registriert: Samstag 21. März 2009, 22:59
Wohnort: Pfaffenwinkel

problembär hat geschrieben: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.
Sehr richtig. McCarthy hat, Paul Graham zufolge, LISP weniger erfunden, als entdeckt. Was er dem zufolge entdeckt hat, war ein neues theoretisches Modell für Berechnungen durch Computer. Er definierte ein paar grundlegende einfache Funktionen und definierte dann mittels dieser die eval-Funktion, die LISP-Programme als Argumente entgegennahm und deren Ergenbis berechnete. Er veröffentlichte es lediglich als Paper, aber "Steve Russell said, look, why don't I program this eval..., and I said to him, ho, ho, you're confusing theory with practice, this eval is intended for reading, not for computing. But he went ahead and did it. That is, he compiled the eval in my paper into [IBM] 704 machine code, fixing bugs, and then advertised this as a Lisp interpreter, which it certainly was. So at that point Lisp had essentially the form that it has today...."
In specifications, Murphy's Law supersedes Ohm's.
BlackJack

@pillmuncher: Ob die Erde wirklich ein besserer Ort wäre wenn mehr Leute Entscheidungen wie Banken und Versicherungen treffen würden!? Dabei wäre mir auch ein wenig unwohl. ;-)
Benutzeravatar
pillmuncher
User
Beiträge: 1484
Registriert: Samstag 21. März 2009, 22:59
Wohnort: Pfaffenwinkel

BlackJack hat geschrieben:@pillmuncher: Ob die Erde wirklich ein besserer Ort wäre wenn mehr Leute Entscheidungen wie Banken und Versicherungen treffen würden!? Dabei wäre mir auch ein wenig unwohl. ;-)
Wie wäre es, wenn AKW-Betreiber gezwungen wären, eine AKW-Haftpflichtversicherung abzuschließen?

Ich denke, das Problem liegt nicht am rationalen Verhalten der Banken und Versicherungen, sondern am irrationalen Verhalten der Wähler, die Politikern Macht an die Hand geben, die sie gegen die Wähler einsetzt, zugunsten des Kapitals. Die letzte Wirtschaftskrise lag nicht am Versagen der Banken, sondern an dem der Politiker, die es den Banken ermöglicht haben, relativ risikofrei abenteuerliche Geschäfte einzufädeln. Das Problem liegt in einer irrationalen Wirtschaftsordnung, die das Recht auf Kapitalvermehrung höher achtet, als jedes andere Recht, und bei der am Ende der gewinnt, der als reichster stirbt.
In specifications, Murphy's Law supersedes Ohm's.
lunar

@pillmuncher: Wo in Gottes Namen sind wir denn jetzt gelandet?! Bei formaler Logik als Waffe gegen die Ausbeitung der Arbeiterklasse durch das Kapitel?! Sorry, aber dieser Sprung ist mir um einiges zu weit. Auch wenn ich die politischen Ansichten, die durch Deine Beiträge schimmern, einigermaßen teile, so ist das erstens vollkommen themenfremd und zweitens übertrieben, polemisch und ziemlich einseitig. Die Welt wäre auch ein besserer Ort, wenn Menschen ihre Argumente und Ansichten mal ausgewogen gestalten würden ...

Im Bezug auf LISP siehst Du die Dinge ähnlich einseitig. Auch wenn Dein Beispiel als Argument nicht taugt, weil es einfach nur einen schlechten Programmierer offenbart, nicht aber allgemeine Schwächen einer bestimmten Entwurfstechnik offenbart, so muss man natürlich zugestehen, dass Programmierer es oft genug an Abstraktion mangeln lassen. LISP (oder beispielsweise auch funktionale Sprachen wie Haskell) ist allerdings nicht die Lösung, sondern meist nur das andere extrem: Vom Problem wird so lange abstrahiert, bis das zu lösenden Problem und mithin auch die Lösung unter all den Abstraktionen nicht mehr zu erkennen ist.

Die Qualität von Programmen ist keine inhärente Eigenschaft einer Sprache, und folgt auch nur sehr bedingt aus der Sprache.
Benutzeravatar
pillmuncher
User
Beiträge: 1484
Registriert: Samstag 21. März 2009, 22:59
Wohnort: Pfaffenwinkel

lunar hat geschrieben:@pillmuncher: Bei formaler Logik als Waffe gegen die Ausbeitung der Arbeiterklasse durch das Kapitel?! [...] Auch wenn ich die politischen Ansichten, die durch Deine Beiträge schimmern, einigermaßen teile, so ist das erstens vollkommen themenfremd und zweitens übertrieben, polemisch und ziemlich einseitig.
Immerhin bin ich da derselben Ansicht wie Otto Neurath. Und im Politischen darf man, finde ich, durchaus polemisch übertreiben, und man muss auch einseitig sein. Die Gegenseite ist es ja auch. Aber das ist tatsächlich OT, also lassen wir das Thema lieber.
lunar hat geschrieben:Auch wenn Dein Beispiel als Argument nicht taugt, weil es einfach nur einen schlechten Programmierer offenbart, nicht aber allgemeine Schwächen einer bestimmten Entwurfstechnik offenbart, so muss man natürlich zugestehen, dass Programmierer es oft genug an Abstraktion mangeln lassen.
Ich habe den Eindruck gewonnen, dass viele, die sich vom Top-Down-Entwurf angezogen fühlen, sich so verhalten, wie ich es beschrieben habe. Ich habe natürlich keine Studie parat, mit der ich das belegen könnte, aber ich hatte ähnliche Erlebnisse oft genug, um ein Muster zu erkennen. Genauso wie du ein Muster bei den LISPern erkennst:
lunar hat geschrieben:LISP (oder beispielsweise auch funktionale Sprachen wie Haskell) ist allerdings nicht die Lösung, sondern meist nur das andere extrem: Vom Problem wird so lange abstrahiert, bis das zu lösenden Problem und mithin auch die Lösung unter all den Abstraktionen nicht mehr zu erkennen ist.
Wie ich schon schrieb, LISPer neigen womöglich dazu, mathematische Eleganz über Lesbarkeit und Praktikabilität zu stellen. Jeder hat so seine Lieblings-Ideen, die er irrational verteidigt und durchzieht, ich möglicherweise ebenso, aber ich bemühe mich, meine immer wieder einer strengen Prüfung zu unterziehen.

Eine dieser Ideen ist, dass Bottom-Up-Entwicklung besser ist. Top-Down-Entwicklung führt IMO immer wieder dazu, dass Lösungen für inexistente Probleme entworfen werden, oder dass die Implementierung entlang der Planungen gar nicht möglich ist, weil manches gar nicht umsetzbar ist. Ein Bekannter von mir sollte mal ein Netzwerk programmieren, bei dem jederzeit neue Knoten dazukommen konnten, die dann ihren nächsten Nachbarn ihre Anwesenheit kundtun sollten, worauf diese die Nachricht weiter zu leiten hatten, bis alle Knoten Bescheid wussten. Das aber, laut Entwurf, in konstanter Zeit. Dazu das von mir genannte Problem mit der Flachheit der Implementation. Mir gefällt das alles nicht.

Auf StackOverflow hat mich mal jemand auf Abschlussdokumente der NATO Software Engineereing Conferences von 1968 und 1969 hingewiesen. Im ersten Jahr kann man mit etwas gutem Willen eine teilweise Favorisierung von proto-agilen Methoden und Bottom-Up-Entwicklung finden, zB. in diesem Beitrag von Kinslow:
The design process is an iterative one. [...] In my terms design consists of:

1. Flowchart until you think you understand the problem.
2. Write code until you realize that you don’t.
3. Go back and re-do the flowchart.
4. Write some more code and iterate to what you feel is the correct solution.
und in diesem von Ross:
The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from. The projects that are called successful, have met their specifications. But those specifications were based upon the designers’ ignorance before they started the job.
Im nächsten Jahr waren diese Stimmen mehr oder weniger verschwunden und Big Design Upfront mittels Top-Down-Entwurf wurde propagiert.

Zum Trost noch ein Beitrag von 1968, von Naur:
…software designers are in a similar position to architects and civil engineers, particularly those concerned with the design of large heterogeneous constructions, such as towns and industrial plants. It therefore seems natural that we should turn to these subjects for ideas about how to attack the design problem. As one single example of such a source of ideas I would like to mention: Christopher Alexander: Notes on the Synthesis of Form.
Die Geschichte der Programmierung ist interessanter als man denkt. Und wie Buffy The Vampire Slayer einst sagte:
Those who fail history are doomed to repeat it in summer school.
Zurück nochmal zu meiner Ausgangsthese, dass der Kern der Programmierung nicht das Technische, sondern das Analytische ist. Da sind LISPer oft näher dran, als die Benutzer von nicht-funktionalen Sprachen. Und natürlich ist:
lunar hat geschrieben:Die Qualität von Programmen ist keine inhärente Eigenschaft einer Sprache, und folgt auch nur sehr bedingt aus der Sprache.
aber jede Sprache zieht gewisse Typen von Programmierern an, die etwas an ihrem Abstraktionsgrad, ihren Konstrukten und ihrem idiomatischen Code finden, was ihnen gefällt und mit dem sie gerne arbeiten. LISP zieht Leute an, die gerne abstrakt über Probleme nachdenken und die Generalisierungen mögen, aus denen sie dann ein Programm als Spezialfall allgemeinerer Konzepte entwickeln. Mir gefällt das. Aber ich sehe selbstverständlich auch, wie das in Übertreibungen enden kann. Die Kunst liegt darin, das richtige Maß zu finden.

Gruß,
Mick.
In specifications, Murphy's Law supersedes Ohm's.
Antworten