Würdet ihr in den Schulen noch FreePascal lehren, wenn ihr ein Fach lehren würdet, bei dem Programmieren das Thema ist?
-
Bashar schrieb:
Bildest du Leute in OOP aus?
Ich musste mal in einer Ausbildung mehr oder weniger aushelfen. Als ich jegliche Programmierung beiseite geschoben hatte, und auf das OO-Prinzip anhand greifbarer Sachen erklärt hatte, hatten es alle nach kurzer Zeit verstanden.
Von da an kamen dann die Programmiergrundlagen (das wesentliche war aber das sie dann mit der OO-Denkweise klar kamen). OO kennt jeder aus dem Alltag, ist garnicht so weit von der menschlichen Denkweise entfernt...
Bashar schrieb:
Woran merkst du, dass Vorkenntnisse in, wie du es nennst, "strukturierter" Programmierung hinderlich sind?
Das wiederum sind gesammelte Erfahrungsberichte aus dem Studium, und ich selber hatte auch die Erfahrung gemacht. Beispielsweise hatte ich und ein paar andere mit Vorkenntnissen in der strukturierten Programmierung anfangs Probleme mit den OO-Konzepten, wo viele ohne Grundlagen das OO-Prinzip schneller verinnerlicht haben (dafür waren die mit Vorkenntnissen im Bereich der Logik etc. etwas weiter).
Bashar schrieb:
Oder merkst man umgekehrt, dass diejenigen, die solche Vorkenntnise nicht hatten, am Ende wesentlich besseres OO-Verständnis haben?
Ich kann nur aus meiner Erfahrung, die ich gemacht habe (ob nun selber, oder im Umkreis Studium, Arbeit...) oder von Dozenten mitbekommen habe zurückschließen. Und danach ist man ggf. bereits in einer anderen Denkweise geprägt, wohin Anfänger noch völlig offen an das Thema gehen.
cu André
-
Tausendsasser schrieb:
Und was kann man mit OOP überhaupt programmieren, wenn man nichts kann? Ist ein if oder eine Schleife oder eine einfache Zuweißung für dich dann auch Teil von OOP?
Im zweiten Schritt ja. Doch lässt man einige Grundpfeiler der strukturierten Programmierung aus (z.B. Trennung Daten und Logik etc).
Ich habe erlebt wenn du OO ohne Programmierung erstmal grundlegend erklärst, und dann anschließend in der Programmierung die entsprechende Richtung einschlägst, das die vorher vermittelten Denkweisen besser verinnerlicht wurden.
-
asc schrieb:
OO kennt jeder aus dem Alltag, ist garnicht so weit von der menschlichen Denkweise entfernt...
Das stimmt ja eigentlich nicht, weil es im Alltag (menschliche) Akteure und passive Objekte gibt, während ein OO-Objekt ohne Verhalten sehr prozedural geprägt wirkt. Ich kann mir nicht vorstellen, dass man nur mit der gesunden Alltagserfahrung bewaffnet ein Monopoly-Spiel so designen würde, dass das Spielfeld dem Spieler, der darauf landet, mitteilt, wieviel Miete er zu zahlen hat. (Beispiel aus dem Buch, das ich gerade lese.)
Du sprichst wahrscheinlich nur von den Grundlagen, was ist eine Klasse, was ein Objekt, was Vererbung usw. seh ich das richtig?
-
Bashar schrieb:
Das stimmt ja eigentlich nicht, weil es im Alltag (menschliche) Akteure und passive Objekte gibt, während ein OO-Objekt ohne Verhalten sehr prozedural geprägt wirkt. Ich kann mir nicht vorstellen, dass man nur mit der gesunden Alltagserfahrung bewaffnet ein Monopoly-Spiel so designen würde, dass das Spielfeld dem Spieler, der darauf landet, mitteilt, wieviel Miete er zu zahlen hat. (Beispiel aus dem Buch, das ich gerade lese.)
der mensch besitzt die möglichkeit zu abstrahieren.
auch schülerInnen oder studentInnen (oder vielleicht gerade die, weil die fantasie noch nicht ganz verschüttet ist) sind fähig, diese abstraktion nachzuvollziehen und sogar selber zu finden.irgendwie unterstellst du lernenden immer einen kurzen blick.
der anfang über katzen, blumen oder autos ist klar nur ein formhaftes lernen, meist mehr schlecht als recht.
wichtig ist natürlich, den sinn..., das konzept..., alles das, was seid jahren pro und contra diskutiert wird, als lehrendeR mitzuliefern über die zeit des unterrichts, sodass die schülerInnen selber einordnen lernen.
sie lernen nachteile und vorteile einschätzen, sie sehen, dass konzepte geschaffen werden von menschen, dass konzepte gewachsen sind über jahrezehnte, dass konzepte 'sich anbieten' für diese oder jene aufgaben, jedoch auch, dass diese konzepte umgestoßen werden können, wenn neues kommt.
tja, es gibt in der pädagogik kein "richtig" und "falsch", ebensowenig wie in der softwareentwicklung.problem ist, dass da meist zu knapp gelehrt wird, ohne hier einen angriff zu fahren, denn die materie hat es in sich, die zeit ist kurz, der/die lehrerende ist in dieser richtung vielleicht auch nicht zu hause, oder die schülerInnen sind einfach zum programmieren nicht geboren, oder oder oder..
-
Mein Vorschlag ist LISP an der Schule (Ja das mit den Klammern...)
Ivo
-
siehe mein Post zu scheme weiter vorn
-
Wenn man mich in der Schule zwingen konnte irgendeinen Biokram zu lernen, kann niemand was gegen LISP oder auch Smalltalk sagen
Ivo
-
Ivo schrieb:
Wenn man mich in der Schule zwingen konnte irgendeinen Biokram zu lernen, kann niemand was gegen LISP oder auch Smalltalk sagen
ja, man kann schüler prima unter druck setzen, mit schlechten noten drohen, erzählen dass ohne lisp im leben nicht weiter kommen, etc.
-
vlad_tepesch schrieb:
scheme ist das letzte, womit ich in der Schule anfangen würde.
Das vergrault doch fast jeden.Im Schulunterricht sollte man schnelle resultate sehen können.
Scheme mag zwar für Unis gut geeignet sein, zur verdeutlichung bestimmter Paradigmen, aber ich wette, dass du damit den meisten leuten den Spaß und die Akzeptanz des Informatik-Unterrichts verdirbst.Mit zB PLT Scheme kannst du doch recht schnell auch Ergebnisse erreichen, die die Schüler ansprechend finden dürften. Also kleine 2d spielchen in denen man Pixelgrafiken über den Bildschirm schiebt oder ähnliches. In nehme einfach an, dass deine Aussage entweder auf schlechter Erfahrung in einem Unikurs oder auf Aberglauben basiert.
~fricky schrieb:
erzählen dass ohne lisp im leben nicht weiter kommen, etc.
Seit wann spielt das eine Rolle in der Schule?
-
Also, ich kann sagen, was ich gemacht habe:
NIKI als Einstieg für Programmierneulinge (Sehr einfach, z.B. keine Variablen)
Delphi zunächst konsolenbasiert, danach ist der Umstieg auf GUI ein Leichtes.
Der Vorteil ist, das NIKI bereits in die grundlegende Struktur eines Pascal-Programmes einführt, ohne wirkliche Syntaxprobleme aufzuwerfen. Aber auch da wirds schon interessant, wenn es z.B. um die Türme von Hanoi geht.Das gute an der Pascal-Syntax ist, dass man kaum Syntaxfehler macht. Ein vergessenes Semikolon ist schnell entdeckt und wird mit einer passenden Fehlermeldung versehen. Auch typische Anfängerfehler (Dangling-Else, Array-Indizes fangen nicht bei 1 an) werden beseitigt.
Ein großes Problem ist meiner Meinung nach die Obligatorik für die Oberstufe. So behandelt man z.B. abstrakte Klassen, virtuelle Funktionen, und alles rund um OOP, allerdings fehlt den Schülern meist die grundlegende Algorithmik. Z.B. einen Algorithmus für den ggT umzusetzen, wäre schon ein Problem. Und solche Schüler setzt man dann vor die Aufgabe, Verschlüsselungsalgorithmen umzusetzen ;).
Gruß
Don06
-
Was elise oben gesagt hat ist zu lang zum Zitieren, aber umso richtiger.
Man verdirbt Schüler nicht so leicht, wie manche hier uns immer weis machen wollen.
Und wenn man Ihnen ein schiefes Konzept beigebracht hat, kann man immer noch
über seine Schwächen sprechen -- das ist manchmal besser, als zehn gute Konzepte zu
liefern.fricky schrieb:
ja, man kann schüler prima unter druck setzen, mit schlechten noten drohen, erzählen dass ohne lisp im leben nicht weiter kommen, etc.
Ist natürlich wahr. Aber das geht mit C genauso.
Immerhin hat man im ANSI-Forum was zu Lachen, wenn man C kann.Aber was den Kern von Scheme angeht, verweise ich
1.) auf Greenspuns zehntes Gesetz und
2.) auf Abelson und Sussman 1985:SICP schrieb:
Although the evaluator described in this chapter is written for a particular dialect of Lisp, it contains the essential structure of an evaluator for any expression-oriented language designed for writing programs for a sequential machine. (In fact, most language processors contain, deep within them, a little ``Lisp'' evaluator.)
In nehme einfach an, dass deine Aussage entweder auf schlechter Erfahrung in einem Unikurs oder auf Aberglauben basiert.
Ich tippe auf Aberglauben.
-
In nehme einfach an, dass deine Aussage entweder auf schlechter Erfahrung in einem Unikurs oder auf Aberglauben basiert.
Ich tippe auf Aberglauben.[/quote]
Aus Erfahrung.
Ich habe selbst erlebt, wie viele meiner Mitstudenten große Probleme mit dieser Sprache hatten.
Das hatte glaub ich folgende Gründe:
- das Paradigma ist ein völlig anderes, als bei den üblichen Anwendungsorientierten Sprachen.
- Die Programme sind recht schwer zu lesen, da sie einen hohen Anteil an Rekursion aufweisen, und car und cdr sich so verdammt ähnlich sehen.
- die Abbildung von fast allem auf Listen sehr gewöhnungsbedürftig ist.Hab ich grad mal aus ner übung im zweiten Semester gekramt ;P
(load "C:/Programme/Scheme/Chez Scheme/lib/record.ss") ; Zuweisung -> Variable Zuweisungsoperator Zahl ; Variable -> Buchstabe | Buchstabe Variable ; Buchstabe -> a | b | c | d | ... | z ; Zahl -> Ziffer | Ziffer Zahl ; Ziffer -> 0 | 1 | ... | 9 ; Zuweisungsoperator -> := Das Spitzensymbol ist Zuweisung. ; ; (variable . varname) ; (zop . :=) ; (zahl . 1234) ; (define scan (lambda (file) (let* ((in (open-input-file file)) ; Datei muss existieren! (out (open-output-file "scan.out" 'replace)) (scan-error (lambda (token x) (close-output-port out) (error 'scan "Fehlerhafte/s ~s : ~s" token x))) (whitespace? (lambda (ch) (memv ch '(#\space #\newline #\tab #\return)))) (ziffer->wert (let ((null (char->integer #\0))) (lambda (ch) (- (char->integer ch) null)))) (buchst? (lambda (ch) (memv ch '(#\a #\b #\c #\d #\e #\f #\g #\h #\i #\j #\k #\l #\m #\n #\o #\p #\q #\r #\s #\t #\u #\v #\w #\x #\y #\z)))) (ziffer? (lambda (ch) (memv ch '(#\0 #\1 #\2 #\3 #\4 #\5 #\6 #\7 #\8 #\9))))) (letrec ((scan0 (lambda () (let ((c (read-char in))) (cond ((whitespace? c) (scan0)) ((eof-object? c) "Scanning finished!") ((buchst? c) (write (scan-var (string c)) out) (scan0)) ((ziffer? c) (write (scan-zahl (ziffer->wert c)) out) (scan0)) ((and (eq? c #\:) ; Zuweisungsoperator (let ((ch (read-char in))) (eq? ch #\=))) (write (cons 'zop ':=) out) (scan0)) (else (scan-error 'token c)))))) (scan-var (lambda (name) (let ((next (peek-char in))) (cond ((whitespace? next) (cons 'variable name)) ((buchst? next) (read-char in) (scan-var (string-append name (string next)))) (else (scan-error 'variable name)))))) (scan-zahl (lambda (wert) (let ((next (peek-char in))) (cond ((whitespace? next) (cons 'zahl wert)) ((ziffer? next) (read-char in) (scan-zahl (+ (* 10 wert) (ziffer->wert next)))) (else (scan-error 'zahl wert))))))) (let ((resultat (scan0))) (close-output-port out) (close-input-port in) resultat))))) ; Aufruf: (scan "x.txt") ; (scan "C:/Eigene Dateien/rene/hs/Wagenknecht/Sprachübersetzer/übungen/x.txt") (define-record zuweisung (var zop zahl)) (define-record variable (var)) (define-record zop (operator)) (define-record zahl (n)) (define parse (lambda () (let* ((in (open-input-file "scan.out")) (out (open-output-file "parse.out" 'replace)) (parse-error (lambda (token) (close-output-port out) (error 'parse "Syntaxfehler in ~s" token)))) (letrec ((parse0 (lambda () (zuweisung))) ; Spitzensymbol (zuweisung (lambda () (write (let* ((v (variable))(z (zop))(n (zahl))) (make-zuweisung v z n)) out))) (variable (lambda () (let ((token (read in))) (if (eq? (car token) 'variable) (make-variable (cdr token)) (parse-error token))))) (zop (lambda () (let ((token (read in))) (if (eq? (car token) 'zop) (make-zop (cdr token)) (parse-error token))))) (zahl (lambda () (let ((token (read in))) (if (eq? (car token) 'zahl) (make-zahl (cdr token)) (parse-error token)))))) (parse0) (close-output-port out) (close-input-port in) (system "rm scan.out") "Parsing finished!")))) ; Aufruf: (parse) (define unparse (letrec ((ast->list (lambda (ast) (variant-case ast (variable (var) (string->symbol var)) (zop (operator) operator) (zahl (n) n) (zuweisung (var zop zahl) (list (ast->list var) (ast->list zop) (ast->list zahl))) (else (error "ast->list: Fehlerhafter AST" ast)))))) (lambda () (let ((resultat (ast->list (call-with-input-file "parse.out" read)))) (system "rm parse.out") resultat)))) ; Aufruf: (unparse)
-
So schlimm ist dein Scheme-Code auch wieder nicht.
Abgesehen davon kann man in einigen Stunden bis Tagen einen Interpreter dafür schreiben,
und zwar in fast jeder Sprache.Die Programme sind recht schwer zu lesen, da sie einen hohen Anteil an Rekursion aufweisen, und car und cdr sich so verdammt ähnlich sehen.
Kannst dir ja auch iterative Makros machen, oft würde auch for-each ausreichen.
die Abbildung von fast allem auf Listen sehr gewöhnungsbedürftig ist.
Aber irgendwie bequemer als die Abbildung von fast allem auf Bitfelder.
das Paradigma ist ein völlig anderes, als bei den üblichen Anwendungsorientierten Sprachen.
Und zwar...?
-
flamer schrieb:
So schlimm ist dein Scheme-Code auch wieder nicht.
Abgesehen davon kann man in einigen Stunden bis Tagen einen Interpreter dafür schreiben,
und zwar in fast jeder Sprache.Hab ich gesagt, dass der Code schlimm ist?
Hab einfach nur mal gekramt und das erst beste genommen.Die Programme sind recht schwer zu lesen, da sie einen hohen Anteil an Rekursion aufweisen, und car und cdr sich so verdammt ähnlich sehen.
Kannst dir ja auch iterative Makros machen, oft würde auch for-each ausreichen.
Das widerspricht wederum dem zugrundeliegendem Paradigma.
Dann kann ich gleich eine Sprache nehmen, die dafür gemacht wurde.die Abbildung von fast allem auf Listen sehr gewöhnungsbedürftig ist.
Aber irgendwie bequemer als die Abbildung von fast allem auf Bitfelder.
Wer bildet denn alles auf bitfelder ab?
das Paradigma ist ein völlig anderes, als bei den üblichen Anwendungsorientierten Sprachen.
Und zwar...?
Ich hoffe, das meinst du nicht ernst.
Die etablierten und im Arbeitsumfeld üblichen Sprachen (c, c++, c#, java, perl, python, php, matlab,...) basieren in der Regel auf dem imperativen oder objektorientierten Paradigma, wohingegen Lisp (also auch Scheme) dem funktionalem Paradigma zuzuordnen ist.
-
elise schrieb:
der mensch besitzt die möglichkeit zu abstrahieren.
auch schülerInnen oder studentInnen (oder vielleicht gerade die, weil die fantasie noch nicht ganz verschüttet ist) sind fähig, diese abstraktion nachzuvollziehen und sogar selber zu finden.Finden sie die auch, wenn man ihnen einschärft, dass die Objektwelt genauso funktioniert wie unser Alltag?
Ich denke nicht.irgendwie unterstellst du lernenden immer einen kurzen blick.
Nein, höchstens mir selbst (ich bin ja auch noch lernend).
Ich verwehre mich einfach gegen die Idee einer Unschuld, die durch Programmiererfahrung verdorben wird und es dem armen Lernenden in Zukunft schwer bis unmöglich macht, den Pfad der Tugend zu beschreiten. Vielleicht kommt diese Idee von Edsger Dijkstra, der "COBOL cripples the mind" und "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC" gesagt hat. Aber da hat er IMHO höchstens eine Korrelation entdeckt.
-
ich glaube, die besten fortschritte in c++ (also mit c++-programmen, die gedichte sind, und keine rätsel) bei leuten gesehen zu haben, die sich vorher in basic ordentlich ausgetobt haben (mit basic-programmen, die augenkrebs erzeugen).
-
-
vlad_tepesch schrieb:
hihi, schaut auch mal auf die seite, wo er mit 'matlab' abrechnet: http://www.henning-thielemann.de/ScriptingHater.html
-
~fricky schrieb:
hihi, schaut auch mal auf die seite, wo er mit 'matlab' abrechnet: http://www.henning-thielemann.de/ScriptingHater.html
Viel zu reißerisch geschrieben, um ernstgenommen zu werden.
-
Bashar schrieb:
Viel zu reißerisch geschrieben
ich mag einen schreibstiel mit viel lästereien. aber naja, dass er sich drüber aufregt, dass matlab bei 1 anfängt zu zählen, anstatt bei 0, ist schon ein bisschen lächerlich.
