Informatiklehrer
-
HumeSikkins schrieb:
Dazu fällt mir spontan folgender Text ein:
http://www.joelonsoftware.com/articles/fog0000000069.htmlYes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.
und er propagiert solchen code? naja, er verkauft ja auch ein bugfix-verfolgungs-programm.
-
volkard schrieb:
daß man sich trotzdem überlegen sollte, was man tut, ist klar.
Eben und dazu ist es noch besser, wenn man es zu Papier bringt und gerade für Anfänger ist das noch wichtiger. Dadurch, dass sie dazu mehr oder minder gezwungen werden ein Struktogramm zu zeichnen, regt man an, dass sie vor dem Programmieren darüber nachdenken, was sie wie überhaupt programmieren wollen.
-
volkard schrieb:
und wenn ich sagte, "wasser ist gesund", kommt ihr mit dem argument, daß schonmal einer im wasser ersoffen ist. viel mehr leute ersaufen im wasser als im bier. na, und?
auf jeden fall hat euer "think once, debug ever"-stil nix in der lehre bei programmieranfängern zu suchen. die kids sollen explorativ proggen. fesseln kriegen sie früh genug.Findest du nicht, dass du jetzt etwas zu sehr verallgemeinerst? Ich kann mich gar nicht erinnern, dass ich irgendeinen "think once, debug ever"-Stil propagiert habe oder irgendeinen anderen Stil. Ich habe nicht mal behauptet, dass mein Stil der Richtige und deiner der Falsche ist. Ich habe lediglich gesagt, dass ich deinen Stil nicht verstehe und zusätzlich meine Erfahrungen wiedergegeben (deshalb auch die vielen imos).
Die Wasser-Aussage kapiere ich btw. schon mal garnicht.und er propagiert solchen code?
Nö. Er weißt auf die Existenz hin. Und er sagt, dass die Existenz solchen Codes häufig auch einen Grund hat, der von Inkompetenz der anderen Programmierer verschieden ist.
naja, er verkauft ja auch ein bugfix-verfolgungs-programm.
Klar. Damit verliert sein Wort natürlich gleich an Gewicht. Verstehe. Was muss man für Software verkaufen, damit man sich mit dir auf einer Ebene unterhalten darf?
Irgendwie kommt es mir so vor, als hättest du jetzt gerade in den Dampfwalzenmodus geschaltet.
-
HumeSikkins schrieb:
Irgendwie kommt es mir so vor, als hättest du jetzt gerade in den Dampfwalzenmodus geschaltet.
sorry. kann sein, daß zu viel ignoranz mich umgab. ich hab mir so viel mühe gegeben, darzulegen, daß frühe festlegungen den code verschlechtern und daß exploratives programmieren den code verbessert. ich lass mich ja auch von euch überzeugen, daß es oft im team randbedingungen gibt, die vorheriges planen (wenigstens ein wenig) nötig machen.
und dann krieg ich so nen hammer:Eben und dazu ist es noch besser, wenn man es zu Papier bringt und gerade für Anfänger ist das noch wichtiger. Dadurch, dass sie dazu mehr oder minder gezwungen werden ein Struktogramm zu zeichnen, regt man an, dass sie vor dem Programmieren darüber nachdenken, was sie wie überhaupt programmieren wollen.
sie sollen doch gar nicht vorher drüber nachdenken.
"think once, debug ever" ist nur das, wo man landen muß, wenn man das vorher-planen und nicht-wegschmeißen ernst nimmt.
die wasser-aussage spielt auf nen bestimmten diskssionsverlauf an, der sich leicht einstellt, wenn einer ne ungewöhnliche these hat.
es ist fast so, als sagte ich "wasser ist gesund" und jemand antwortete "aber im wasser ersoff mal einer". jedes verhamlosen von mir wie "aber da ersaufen doch nur selten leute" wird sicher sofort erwidert mit "aber mein schwager seine frau auch!" oder so. bis irgendwann jeder von seiner tante was beigetragen hat und ich für viele wie ein idiot dastehe.aber nach ajs letztem posting vergeht mir eh die lust an diesem thread. am wochendende werd ich noch den verlauf vom wpc112 posten.
-
AJ schrieb:
Eben und dazu ist es noch besser, wenn man es zu Papier bringt und gerade für Anfänger ist das noch wichtiger. Dadurch, dass sie dazu mehr oder minder gezwungen werden ein Struktogramm zu zeichnen, regt man an, dass sie vor dem Programmieren darüber nachdenken, was sie wie überhaupt programmieren wollen.
kannst du dich überhaupt daran erinnern, wie es damals als anfänger war?
-
aber nach ajs letztem posting vergeht mir eh die lust an diesem thread
Die hatte ich für meinen Teil sowieso ignoriert
(keine Böswilligkeit. Erklärung steht weiter unten.)
Ich wollte dir erst noch meinen Standpunkt klar machen um dann besser mit dir diskutieren zu können. Wie du ja weißt, habe ich immer Schwierigkeiten damit mich auf mehrere Dinge gleichzeitig zu konzentrieren.Naja, vielleicht sollten wir das Thema auf das nächste Forumtreffen verschieben. Das Instabilität des Forums zur Zeit macht ein ernstes Gespräch imo sowieso viel zu anstrengend.
-
@volkard
Ja kann ich, da es ja noch nicht all zu lange her ist (ca. 5 1/2 Jahren hats angefangen). Mich hat es auch immer genervt, dass wir vor dem Programmieren Struktogramme zeichnen mussten, aber im Nachhinein finde ich es ganz gut so.@volkard & humesikkins
Was war denn bitte so schlimm an meinem letzten Posting??
-
Hi Volkard,
ich verdiene mein Geld mit der Entwicklung/Design von Software, wohl genau wie du.
Ich habe in diesem Formu schon viele gute Beiträge von dir gelesen und habe mir
gedacht der hat ordenlich was auf dem Kasten.
Wenn ich jedoch so lese was du in diesem Beitrag alles zum Besten gibst, hoffe ich
nur das du dich überwiegend ironisch oder zumindestens überspitzt ausgedrückt hast.
Ansonsten hätte sich meine Meinung über dich erheblich geändert.
Du gibst Sachen von dir, die ich von einem Entwickler der im Team Projekte mittlerer
bis grosser Grösse entwickelt nicht erwartet habe.z.B.
"DER PLAN" muss beim coden entstehen.
Da ich als Teamleiter auch für die Einbeziehung von Freelancern zuständig bin, muss
ich dir sagen das ich jemanden mit dieser Vorstellung von einer professionellen Projektwicklung,
weder als freien und noch viel weniger als ständigen Mitarbeiter gebrauchen kann. Da du
offentsichlich sowohl von C++ als vom Design wirklich Ahnung hast finde ich das wirklich
ziemlich schade.
Für mich bist du damit der Prototyp eines "genialen" Hackers bzw. Einzelkämpfers mit
ausserordenlich viel Sachverstand, jedoch ungeeignet zur planvollen und kontinuierlichen
Entwicklung grosser Software-Projekte. Einsetzbar überall dort wo plötzlich Probleme und
Fehler auftreten, die mit keiner noch so guten Planung verhindert werden können, richtig !!Das mit dem wegschmeissen sehe ich übrigens genauso
mfg JJ
-
AJ schrieb:
Mich hat es auch immer genervt, dass wir vor dem Programmieren Struktogramme zeichnen mussten, aber im Nachhinein finde ich es ganz gut so.
Ich habe den Sinn von Struktogrammen nie gesehen.
Mein Vater steht zwar auch drauf, aber er mag ja auch Pascal am liebsten - insofern kann ich ihn nicht immer ernst nehmen.
-
volkard schrieb:
am wochendende werd ich noch den verlauf vom wpc112 posten.
Es ist Wochenende
-
John Doe schrieb:
...oder zumindestens überspitzt ausgedrückt hast
das kann schon sein. das mache ich doch immer.
evtl muss erwähnt werden, daß "spät planen" und "gar keinen plan haben" durchaus unterschiedliche sachen sind.
[quote="John Doe"]Das mit dem wegschmeissen sehe ich übrigens genauso[quote]
aha. da hab ich doch schon mal nen ansatzpunkt. machmal kippt software um. sie wird unwartbar und unerweiterbar (manche schafft es sogar, während der entwickling umzukippen). das ist immer folge eines schlechten planes. das phänomen kennste sicherlich und es ist eigentlich genau das, was nicht passieren darf.mir passiert das seltener. weil ich normalerweise nen guten plan habe. und warum ist mein plan gut? weil er erst spät aus den wirren versuchen und überlegungen kondensiert. alleine dauert's meist 1/3 der gesamten entwicklngszeit, bis der plan fest steht. nicht fest im sinne von "verankert", sondern im sinne von "stabil", er braucht nicht mehr verbessert zu werden.
im team oder wenn randbedingungen ne suboptimale lösung erfordern, muss man auch festlegen, bevor der plan von selber stabil ist. aber auch da könnte ich mir nur unter schmerzen weniger als ein bis zwei wochen geben, um nen plan reifen zu lassen, der wenigstens so stabil erscheint, daß auch laien ihn ausprogrammieren können.
was ich aber nicht machen würde, gegebenenfalls durch kündigung unterstützt, ist am esten tag nen plan zu fassen. das hat einfach keinen sinn und der frühe plan stirbt sicher.
Für mich bist du damit der Prototyp eines "genialen" Hackers bzw. Einzelkämpfers mit ausserordenlich viel Sachverstand, jedoch ungeeignet zur planvollen und kontinuierlichen Entwicklung grosser Software-Projekte.
es kann sein, daß ich noch 15 jahre warten muss, bis die zeit für meinen stil reif ist.
-
wie es weiter ging nach dem
while(das while( hatte augenblicklich die tendenz, zu einem insetion sort
heranzuwachsen. zuerst die segmente sortieren und dann in einem linearen
rutsch auswerten.
(plan1: sortieren und dann in linearer zeit auswerten)und insertion sort ist bei so kleinen arrays gut. dann sah ich, daß kein
sort im eigentlichen sinne optimal ist, sondern ne abwandlung, wobei
segmente, die sich überschneiden, sofort zusammengefasst werden.
(plan2: ein beliebiges sortierverfahren dahingehend abwandeln, dass
sich schneidende segmente beim sortieren zusammengefasst werden)und sortieren tut nicht not. wenn eh jedes segment mit jedem anderen verglichen
wird, kann ich auch nur zusammenfassen und nix sortieren.
(plan3: plan2 ohne sortieren)hab auf papier diese abwandlung von insertion sort geprobt
(plan4: insertion sort nehmen)
(war nicht elegant).dann von heap sort
(plan5: heap sort)
(war nicht geeignet abwandelbar).(plan6: wieder insertion sort)
insertion sort hatte beim implementieren schluckauf. so viele sonderfälle
und nacharbeiten, daß es unspaßig wurde (>100% gepfuschte nacharbeiten).(plan 7: selection sort)
selection sort (in place, ohne lokale kopie des keys) aber war dann angenehm.
(plan 8: selection sort mit zusammenfassen ohne sortieren. der plan hat (zufällig?)
bis zum ende gehalten.)ich hab viele formale ersetzungen auf code-level gemacht.
so sachen wiea; while(b){ c; d; }wird zu
for(a;b;d) c;(deswegen isses auch nicht schlimm, wenn ich mit while anfange. der code wird eh
umgebastelt und es bleibt nur code stehen, den ich "hübsch" finde.)eine ersetzung sei besonders erwähnt:
int x=0; for(i=0;i<KONST;++i) for(...) if(...) ... goto outercontinue; ++x; ouerconftinue:; return x;war ein wenig unfein.
mit ner standard-transformation führte ich über in:int x=KONST; for(i=0;i<KONST;++i) for(...) if(...) ... --x; goto outercontinue; outercontiune:; return x;(x=KONST;...;--x;...;return x; führt erfahrungsgemäß zu besserem code als das
von der konkurrenz lieber genommene x=0;...;++x;...;return KONST-x;)
und das zerfällt am freien sauerstoff sofort zuint x=KONST; for(i=0;i<KONST;++i) for(...) if(...) ... --x; break; return x;dann begann ich intensiv zu testen und bekam ausnahmefälle, die ich mit bis zu zehn zeilen
code vorher rausfischte (oh, wieder 100%). hab die dann auch eher formal in die hauptschleife
geknäult (drei zeilen). und dann saß ich in nem lokalen maximum. keine offensichtliche
transformation kann den code mehr verbessern. und da der code sich bereits recht gut anfühlt,
strebe ich nicht nach anderem, sonder sollte mal kapieren, was da passiert ist.übrigens hätte ich den afänglichen code (mit goto und so) kaum richtig kapieren können.
nach den transformationen klappt's aber. und kapieren ist recht hilfreich, wenn's um
glaubwürdige fehlerfreiheit geht und kapieren ist notwendig für ale nichttrivialen
optimierungen.und dann erst hab ich mir beim kommentieren bedeutungen überlegt!
und siehe, es war gut.int wpc112(int *start, int *end, int n) { (1)int result=n;//think of n distinct line segments (3)for(int s=n-1;s>=0;--s){//source runs from last entry to first entry (2) if(start[s]==end[s]){//if source is a bad entry (2) --result;//ignore it qickly if it were never there (2) continue; (2) } for(int t=s-1;t>=0;--t){//the targets are all entries above the source if(start[s]<=end[t] && end[s]>=start[t]){//if the source meets a target if(start[s]<start[t])//join them by updating the target to start[t]=start[s];//the smaller start if(end[s]>end[t])//and the greater end end[t]=end[s]; (1) --result;//these line segments were not distinct (1) break;//source vanished by joining with target, we can go to next source } } //nota bene: if no target joined with this source, it's safe to forget this source //there is no way to join it with any combination of targets } (1)return result; }(1)die oben erwähnte transformation führte zu kürzerem code und mehr noch,
die bedeutung ist klarer, als die des langen codes. kurzer code ist oft auch
einfacher code.
(2)die langen vorarbeiten, die bad entrys zu löschen, kann man sich fein sparen,
wenn man sie in der hauptschleife ignoriert. man könnte sich das sogar inhaltlich
überlegt gehabt haben, aber wozu so kompliziert, wenn es auch von selber kommt?
(3)durch den trick (2) musste die schleife statt >0 jetzt >=0 fragen, um beim
ersten element im bad-fall auch --result zu machen. auch nicht überlegt, sondern
debuggt.
(1)es ist GUT, daß --result passiert, wenn gejoined wird. ich zahle fürs zählen
genau dann, wenn der algo durch joinen ne verbesserung für nachfolgende schleifen
erzielt. die kosten werden toll überkompensiert.
und wenn nix zu joinen ist, wird trocken durchgerast. damit sollte mich kein trocken
durchrasender konkurrent schlagen, denn das kann ich auch. und bei den optimierenden
konkurrenten gehe ich davon aus, daß sie umständlichen code bauen und mir ne faire chance
lassen.
mal grenzfälle betrachten. je mit 10 entries.
wenn lauter bad entries da sind, passieren 10 vergleiche (außer der schleifensteuerung)
10 lokale dekrementierungen und fertig. schlicht optimal, würde ich sagen.
wenn lauter disjunkte etries da sind, passieren 10 vergleiche und 45 doppelvergleiche
und schluss.
die sortierende zunft, würde nach dem sortieren nur 10 vergleiche haben, aber beim
sortieren 55 vergleiche und etliche nichtlokale doppelswaps (vierfachzuweisungen)!
die alternative, ein schnelleres verfahren als O(n^2) zu nehmen, fällt bei 10 entries
flach, es wäre noch teurer.
bei lauter gleichen good entries, passieren 10 vergleiche, 9 doppelvergleiche und noch
18 vergleiche und 9 lokale dekrementierungen. da hat der sorterende noch gar nicht
angefangen. hätte einer gegen lauter gleiche nen sonderfallchecker davor, brächte der
vermutlich zu große fixkosten.
mir scheint, ich brauche mich vor sonderfallsammlern nicht sehr zu füchten und vor
sortieren auch nicht sehr. und das sind die beiden einzigen nichtverwandten gegner,
würde ich sagen.
und die verwandten? also gegner, die auch die entries gegeneinander vergleichen und joinen?
merge-sort als rumpf zum könnte stärker sein, aber vermutlich wird die verwaltung viel
zu teuer, entweder viele datenstrukturen oder rekursion. unter den O(n^2)-sorts
kann ich keine luft mehr sehen, wie man nen vergleich oder ne zuweisung sparen könnte.
ob es jemand schafft, lokalere zuweisungen zu bekommen, riskiere ich. (später
umentschieden.)ich halte es für unmöglich, auch nur ansatzweise im vorhinein abchecken zu können, wie
sich solch ein algo genau entwickeln wird. und jeder versuch, den algo vorher auf papier
zu bannen, ist grober unfug.
die papierarbeit war auch kein bannen, sondern nur sowas wie münzenschieben. sofort nach
der schiebung ist die aufgezeichnete information wertlos. sie hat NICHT den charakter
von struktogrammen oder uml-diagrammen oder automatentabellen, die danach in code
übersetzt werden sollen.dann kam raus, daß bad entries gar nicht weg müssen. naja, weg mit den 3 zeilen dafür.
dann wurde im forum ne lösung gepostet, die fast gleich zu meiner war. die schleifen laufen
andersrum. und er läuft mit zeigern und macht lokale kopien, um schneller zu sein.
an zeiger glaub ich nicht mehr. ich konnte nicht durch messungen bestätigen, daß die schneller
als indexzugriffe sind. und in diesem fall hat man mit start, end und i weniger variablen zu
brauchen als mit start, end, ps, pe. das zahlt sich gerne aus durch mehr register-variablen.hab wohl mit plan 8 gut getroffen. jetzt noch ein paar mikro-optimerungen.
alles wieder transformationen, die kaum der rede wert sind.int wpc112(int *start, int *end, int n) { int result=n;//think of n distinct line segments for(int& s=n;--s;){//(s is an other name für n) while there are line segments left int t=0;//target starts at 0 do{//and runs till just before n if(end[s]>=start[t]){//if the source ... int start_s=start[s];//(start_s is an other (faster) name for start[s]) if(start_s<=end[t]){//...meets a target --result;//the source will vanish if(start[t]>start_s)//join source and target by updating the target to start[t]=start_s;//the smaller start if(end[t]<end[s])//and the greater end end[t]=end[s]; break;//source vanished by joining with target, we can go to next source } } }while(++t<s); }; return result; }mal sehen, was die konkurrenz sich ausdent und ob ich was wesentliches übersehen hab.
die sachen auf papier waren tests, keine pläne.
[url="http://volkard.de/plan2.tif"]
[url="http://volkard.de/plan1.tif"]---
am freitag ging ich in die stadtbücherei. und da lächelte mich ein buch an und
sagte "lies mich". es heißt "Logik der Programmierung".
drinnen lernt man allerhand.
unter anderem, daß man programme mit struktogrammen planen muss, bevor man sie
eintippt.
auf seite 5-05 findet sich ne aufgabe "es ist eine liste der mitarbeiter
der unernehmung xyz auszudrucken. auf jeder seite dieser liste steht eine
überschriftenzeile, es schließt sich eine leerzeile an, und dann erfolgt
zeile für zeile eine auflistung der mitarbeiter. [...]Pro Seite dürfen nicht
mehr als 30 Zeilen gedruckt werden.[...]"
der autor ist auch nett und gibt eine musterlösung an.
[url="http://volkard.de/plan3.tif"]
ich übersetze mal in pseudocode:dateien ein_dat und aus_dat öffnen zeile1_flag=true zeilen_zaehler=0 zeile von ein_dat lesen solange nicht eof(ein_dat) wenn zeile1_flag==true ueberschrift ausgeben (inc zeilen_zaehler+=2, zeile1_flag=false) mitarbeiterzeile ausgeben (inc zeile1_zaehler+=1) wenn zeilen_zaehler>29 zeile1_flag=true zeilen_zaehler=0 zeile von ein_dat lesen dateien ein_dat und aus_dat schließenfällt euch daran was auf?
.
.
.
.
--spoiler
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
es sollte folgendes auffalen: die variable zeile1_flag ist komplett
nutzlos. das programm sollte zerfallen indateien ein_dat und aus_dat öffnen zeilen_zaehler=0 zeile von ein_dat lesen solange nicht eof(ein_dat) wenn zeilen_zaehler==0 ueberschrift ausgeben (inc zeilen_zaehler+=2) mitarbeiterzeile ausgeben (inc zeile1_zaehler+=1) wenn zeilen_zaehler>29 zeilen_zaehler=0 zeile von ein_dat lesen dateien ein_dat und aus_dat schließendas weghauen einer unfugs-variablen ist eigentlich ne planabweichung.
-
Deine Bilder tun nciht.
-
dEUs schrieb:
Deine Bilder tun nciht.
tun jetzt.
-
Natürlich muss man, wenn man ein Problem im Team angehen möchte, vorher einen Plan aufstellen oder zumindist das Problem in mehrere Teile teilen und Schnittstellen definieren.
schnittstellenverhandlungen geschehen unter profis so:
"ich muss bei dir gucken können, welche dateien du verändert hast"
"magste nen vector?"
"jo"
"kriegste"Ich mag bezweifeln das man, bei mittelgroßen oder großen Projekten, mit einer mündlichen absprache dieser Art ein lauffähiges Programm zusammen bekommt.
--
er soll erstmal coden lernen! dann entwerfen. und nicht wie heutzutage andersrum. das kann nix werden. oder sollen schüler zuerst englische aufsätze schreiben und lernen erst im studium dann die vokabeln dazu?
Steinigt mich meinetwegen, aber ich denke in der Schule sollte _keine_ Programmiersprache gelernt werden. Schüler sollten lernen ein Problem abstrakt zu behandeln, es zu verstehen, und so zu einer Lösung zu gelangen. So sollten die standard Soriteralgorithmen, Bäume und ähnliches behandelt werden.
Ein Bubblesort, wenn man es vorher erklärt, kann ein Schüler natürlich programmieren indem er den Computer startet, drauf los hackt und solange probiert bis es funktioniert. Aber verstehen wie es funktioniert und was der Computer eigentlich macht kann er besser auf dem Papier.
Erst danach sollte man, in einem Projekt, meinetwegen auch im Unterricht oder in einer Berufsausbildung die Syntax einer Programmiersprache erlernen.So fällt es dem Schüler später leichter sich neue Programmiersprachen zu erlernen. Man kommt Heutzutage im Beruf nunmal nicht mehr mit den kenntnissen einer Programmiersprache aus.
Die Informatik ist nunmal eine Sonderform der Mathematik und sollte auch in der Schule, meiner Meinung nach, so behandelt werden.
-
borg schrieb:
Steinigt mich meinetwegen, aber ich denke in der Schule sollte _keine_ Programmiersprache gelernt werden. Schüler sollten lernen ein Problem abstrakt zu behandeln, es zu verstehen, und so zu einer Lösung zu gelangen. So sollten die standard Soriteralgorithmen, Bäume und ähnliches behandelt werden.
Du willst etwas abstrakt erklären, ohne dass jemand einen konkreten Bezug dazu hat. Das halte ich für gewagt. Denn wenn man zB Bäume erklärt, dann kann sich der Schüler erstmal nix darunter vorstellen. Wie? eine Wurzel? Und die ganz oben? Was soll der Blödsinn? Rekursiv? Hilfe!
Warum nicht eine Sprache nehmen - ist ja egal welche - und den Schülern es damit erklären. Es muss laufen und sich anfühlen können, sonst bringt es nix.
In Mathematik machen wir zuerst immer die Theorie. zB bei der Preis und Kostentheorie (wenn es jemand nicht kennt: im Prinzip simpelste Funktionsdiskussionen) habe ich es stark gemerkt: am Anfang hat niemand auch nur annähernd kapiert was es damit auf sich hat. Erst als wir Beispiele gerechnet haben, haben wir es kapiert.
In Informatik ist es genauso. Ich kann jemanden erklären was ein Baum ist, aber er wird es nicht wirklich verstehen. Weil es keine Anhaltepunkte gibt, die er kennt und an die er sich halten kann.
Wenn man das ganze jetzt in einer Sprache implementiert (welche ist ja egal - sollte nur möglichst einfach zu lernen sein) dann habe ich etwas zum anfassen.
Die Alternative wäre, es grafisch zu erklären (es gibt n paar tolle JavaApplets die Bäume zeigen, man kann hinzufügen, suchen, etc. und das Applet zeigt die einzelnen Schritte). Sowas wäre auch denkbar. Allerdings denke ich, dass es besser ist, wenn man die Strukturen selber implementiert. Man muss ja nicht gleich einen besonders ausgefeilten Baum implementieren - zB ein kleiner Binärbaum und den rest grafisch erklären. Mit sowas könnte man IMHO mehr anfangen.
Wenn man eine Datenstruktur in einer Sprache implementieren kann, dann ist es ja kein Problem sie in andere Sprachen umzulegen.
Aber verstehen wie es funktioniert und was der Computer eigentlich macht kann er besser auf dem Papier.
Naja. Sobald man aber ein Bubblesort oder so selber implementiert hat, sieht man die ganzen Algorithmen aber ganz anders.
So fällt es dem Schüler später leichter sich neue Programmiersprachen zu erlernen. Man kommt Heutzutage im Beruf nunmal nicht mehr mit den kenntnissen einer Programmiersprache aus.
Und wenn man zB Pascal 'kann' (die Grundlagen reichen ja - man muss ja nicht was weiss ich wie gut sein um einen Baum oder ne Liste zu implementieren) dann kann ich mein Wissen auf alle anderen prozedualen Sprachen anwenden - und die Datenstrukturen kann ich auch überall verwenden. Ich sehe da keine besonderen Hindernisse.
Allerdings stimme ich dir zu, dass man keine Programmiersprache lernen sollte. Dennoch denke ich, dass man die Datenstrukturen und Algorithmen zumindest zu einem kleinen Teil selber implementieren können sollte.
Die Informatik ist nunmal eine Sonderform der Mathematik und sollte auch in der Schule, meiner Meinung nach, so behandelt werden.
Genau. Und was macht man in Mathe?
Beispiele rechnen.zB bei Funktionen habe ich erst Beispiele rechnen müssen und wirklich verstehen lernen müssen was die verschiedenen Ableitungen bedeuten bevor ich mich wirklich ausgekannt habe.
-
Also ein Info-Unterricht ohne das Erlernen einer Programmierersprache wäre für mich undenkbar. Komplexe Algorithmen und andere theoretische Inhalte lassen sich am besten Verstehen, indem man sie selber anwendet, nachdem man sie theoretisch besprochen hat, und dazu ist nunmal das Kennen einer Programmierersprache notwendig. Außerdem glaube ich kaum, dass man Begeisterung für die Informatik wecken kann, indem man nur trockene theoretische Inhalte vermittelt. Das schönste am Programmieren, oder besser gesagt der Informatik, ist es doch zu sehen, wie man dank seiner Kenntnisse etwas "erschafft". Die stark motivierende Komponente kommt in der Schule sowieso für meine Begriffe viel zu kurz. Auch die Notwendigkeit einer guten Projektplanung, der Arbeitsteilung und der damit verbundenen Notwendigkeit von Kommunikation und die saubere Programmierung mittels OOP werden doch erst dann wirklich deutlich, wenn man bei einer praktischen Arbeit mal in die Falle reintappt und einsieht, dass solche Dinge wirklich notwendig sind und nicht nur aufgezwungene Leitlinien des Lehrers sind.
Allerdings sollte das Erlernen und Anwenden einer Programmierersprache wie schon gesagt nur einen kleinen Teil des Unterrichts ausmachen. Zusätzlich bin ich aber noch der Meinung, dass neben der objekt-orientierten Programmierung, auch noch andere Sprachkonzepte zumindestens angeschnitten werden sollten. Prolog und C bilden doch einen rechten starken Gegensatz zur Programmierung in C++ oder Java. Auch Datenbanken könnten ruhig mal angeschnitten werden.
-
Allerdings stimme ich dir zu, dass man keine Programmiersprache lernen sollte. Dennoch denke ich, dass man die Datenstrukturen und Algorithmen zumindest zu einem kleinen Teil selber implementieren können sollte.
...
Genau. Und was macht man in Mathe?
Beispiele rechnen.zB bei Funktionen habe ich erst Beispiele rechnen müssen und wirklich verstehen lernen müssen was die verschiedenen Ableitungen bedeuten bevor ich mich wirklich ausgekannt habe.
Stimmt natürlich, auch was Michamab sagt, habt recht. Hab ein wenig überspitzt auf die oben zitierte Aussage volkards reagiert. Ich wollte eigentlich nur sagen das es ein total falscher Ansatz ist einem Schüler zu sagen "erst programmieren, dann denken". Dazu tendiert man am anfang und es ist ein falscher Ansatz wenn man etwas lernen möchte.
-
Shade Of Mine schrieb:
AJ schrieb:
Mich hat es auch immer genervt, dass wir vor dem Programmieren Struktogramme zeichnen mussten, aber im Nachhinein finde ich es ganz gut so.
Ich habe den Sinn von Struktogrammen nie gesehen.
Mein Vater steht zwar auch drauf, aber er mag ja auch Pascal am liebsten - insofern kann ich ihn nicht immer ernst nehmen.Das wichtige dabei war ja, dass man vor dem Programmieren erstmal drüber nachgedacht hat, was man programmiert und bei Anfängern finde ich das wichtig. Wobei man vielleicht auch andere Methoden verwenden hätte können, um das zu erreichen, aber zumindest war es somit fächerübergreifend (= das große Schlagwort :D).
Einen Sinn am Struktogramm an sich sehe ich auch nicht; Da kann man ja gleich den Quellcode hinschreiben.