Würdet ihr in den Schulen noch FreePascal lehren, wenn ihr ein Fach lehren würdet, bei dem Programmieren das Thema ist?
-
Vielleicht. Für den Einstieg würde ich auf jeden Fall etwas sehr einfaches wählen, da die Leute sonst nicht nachkommen und Programme schreiben, die sie nicht einmal verstehen (Java: 'Warum
class? Warumpublic static void main(String[] args)? Warum nicht einfachprintln("Hallo, Welt!");?' ;)) und da scheint mir Pascal in seiner Urform gar nicht mal so abwegig. Allerdings ist es eben schon so, dass die Sprache und ihre nächsten Verwandten sehr selten geworden ist.Besser scheint mir da C, und ich meine das reine C. Es ist für den Einsteiger mit Sicherheit ein harter Brocken, und man müsste sehr langsam vorwärts machen damit die Leute auch nach kommen. Anhand von C kann man dann gut alle Grundkonzepte (z.B. Zeiger!
Viele Sprachen verstecken diese vor dem Programmierer, in C sind sie jedoch schön explizit. Implementier in Java eine doppelt verkettete Liste und die Leute werden auch nach Jahren noch fragen, warum das funktioniert, wenn sie Referenzen/Zeiger/Handles oder wie man es nun auch immer nennen mag nicht verstehen) vermitteln, die dann in anderen Sprachen von Nutzen sein werden. Weiterhin ist die C Sprachfamilie lebendig (siehe C++, C#, Java, ...); ein Umstieg besteht zu grossen Teilen aus einem Dazulernen und nicht aus einem Umlernen.Allgemein finde ich es eine sehr schwierige Frage, was man denn nun lehren sollte. Persönlich denke ich sowieso, dass die meisten guten Programmierer nicht erst an den Schulen und Universitäten "gemacht" werden. QuickBASIC mit 8 Jahren anyone?
-
damit versteht man Computer vielleicht ein bisschen besser versteht.
<pedantic>Registermaschinen</pedantic>
Trotzdem glaube ich, daß ein Anfänger, der mit
smalltalk oder scheme gelernt hat, enttäuscht sein könnte, wenn er auf andere
Sprachen mit komplizierter Syntax usw. umsteigt.Dann läßt er's eben bleiben...
-
Als wenn man schon bereit ist C zu nehmen, dann bietet sich ja wohl D am ehsten an.
Gruss
Flamers Brennstoff.
-
flamer schrieb:
damit versteht man Computer vielleicht ein bisschen besser versteht.
<pedantic>Registermaschinen</pedantic>
<pedantic++>endliche Automaten<pedantic++>
-
asc schrieb:
Das Stimmt nicht. Wenn man keinerlei Programmiervorkenntnisse hat, können die Grundlagen von OOP sogar durchaus leichter verständlich erklärt werden (Kommt aber auch darauf an wie man das ganze angeht, ich habe z.B. die Programmierung als solche erst nach der Vermittlung der OO-Grundlagen vermittelt).
Erzähl mal. Bildest du Leute in OOP aus? Woran merkst du, dass Vorkenntnisse in, wie du es nennst, "strukturierter" Programmierung hinderlich sind? Oder merkst man umgekehrt, dass diejenigen, die solche Vorkenntnise nicht hatten, am Ende wesentlich besseres OO-Verständnis haben?
Würde mich einfach mal interessieren.
-
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.
-
asc schrieb:
Das Stimmt nicht. Wenn man keinerlei Programmiervorkenntnisse hat, können die Grundlagen von OOP sogar durchaus leichter verständlich erklärt werden (Kommt aber auch darauf an wie man das ganze angeht, ich habe z.B. die Programmierung als solche erst nach der Vermittlung der OO-Grundlagen vermittelt).
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?
-
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?
hängt davon ab, wie ernst die jeweilige Sprache das OO-Prinzip nimmt.
In Smalltalk ist es das, ja. whileTrue ist eine message, die an einen Block gesendet wird.
Schleifen bspw. sind auch messages an Objekte:1 to: 10 do: [ :i | Transcript show: cr ]
-
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)
