Informatiklehrer

[over'load]

Um auch mal was zum Thema Informatiklehrer zu sagen:
Unser Infolehrer stinkt jede Stunde nach Bier (wirklich üble Fahne [Haben den auch in Mathe, aber da stinkt er nicht... liegt vielleicht daran, dass Info in die Randstunden fällt ;)]). Teilweise halte ich ihn für inkompetent, Dauerzitat zum Beispiel: "Was macht denn jetzt die Prozedur 'lies'?"
Sie sieht so aus:

PROCEDURE lies(VAR c: CHAR);
   REPEAT c := UPCASE(READKEY) UNTIL c IN E;
END;

Ich bin in der 11. Klasse, habe aber Informatik mit der 12 und 13 zusammen, weil es zu wenig Leute wählen (warum eigentlich?). Zur Zeit sind wir über Zeiger zu Automaten und Sprachstrukturen gekommen, wollen ab nächster Stunde mit Assembler und Micorsim beginnen und danach Java anfangen. Obwohl das zu hoch für ihn sein wird...

[dEUs]

lol.
Wenn ich das richtig mitbekommen habe, gibt es bei uns inzwischen nicht mal mehr einen freiwilligen Informatikkurs. Letztes Jahr (11. Klasse) gabs den noch, haben sich recht viele angemeldet (20 oder 25 Leute). Aber das sind fast mit jeder Stunde weniger geworden und am Ende des ersten Halbjahres war dann keiner mehr da
Mein Lehrer war garnicht mal soo übel inkompetent, da hatte ich an der Schule schon schlimmere, aber so richtig den Plan hatte er auch nicht. Am Anfang hab ich noch auf den Schulrechnern brav mitgearbeitet. Irgendwann wurde mir das zu doof, weil ich so schnell fertig war und dann nur rumgesessen bin. Dann hab ich meinen Laptop mitgebracht und meinen Kram programmiert und Musik gehört. Ich war dann eigentlich nur noch für Fragen des Lehrers da, falls der was wissen musste Irgendwann war's mir dann zu doof und ich bin nicht mehr hin.
Für Programmieranfänger war's meiner Meinung ok, aber sowas hat man bei uns auch schon in der 8. Klasse gemacht, deswegen hatte ich ein etwas höheres Niveau erwartet

[Nobuo T]

*lol* Wenn ich das hier so hoere, scheine ich es ja noch relativ gut getroffen zu haben an meiner Anstalt - zumindest was peinliche Auftriit des Infolehrers betrifft.

Insgesammt haben wir ~4 "Informatiklehrer", von denen aber eigentlich nur 2 als halbwegs kompetent zu bezeichnen sind und keinen LK.
Einer von diesen beiden hat vor 15Jahren sogar mal in Assembler gecoded *wow* - da kann man wirklich noch ein bissel Eindruck schinden mit den schoen gruenen Zeilen im TurboPascal.

Also auch wenn deren Wissen (inzwischen...?) nicht ueber TurboPascal/Delphi und ein bissel HTML hinausreicht - das bissel wird wenigstens gut vermittelt.
Ausser der Aussage, dass FrontPage gut geeignet sei, auch groessere Homepages zu erstellen und man seine Pascal-Programmen in so viele Prozeduren wie nur irgendmoeglich unterteilen sollte, ist da noch nichts wirklich peinliches vorgekommen.

Bin lediglich erstaunt, was einige hier schon alles an Themen durchgenommen haben.
In den ersten beiden Semestern liess der Pauker uns mal ein bissel mit Pascal/Delphi/FrontPage rumspielen - keine weitere Thematik, ausser was sind Arrays / wie funktioniert Dateiverarbeitung in Pascal usw.
Und in den aktuellen Semestern gab es verkettete Listen mit Pointern und Sortieralgorithmen (zB. Quicksort).
Also wirklich uebelst langweilig.

[Nobuo T]

dEUs schrieb:

Dann hab ich meinen Laptop mitgebracht und meinen Kram programmiert und Musik gehört. Ich war dann eigentlich nur noch für Fragen des Lehrers da, falls der was wissen musste Irgendwann war's mir dann zu doof und ich bin nicht mehr hin.

Nicht schlecht, nur was tun, wenn man noch kein eigenen Laptop hat.
Ich habe mir zumindest irgendwann dann mal einen SNES-Emulator runtergeladen und Chrono-Trigger gezoggd.
BTW: Gibt es bei euch nur freiwilligen Info-Unterricht?

dEUs schrieb:

Für Programmieranfänger war's meiner Meinung ok, aber sowas hat man bei uns auch schon in der 8. Klasse gemacht, deswegen hatte ich ein etwas höheres Niveau erwartet

Leider sind wohl in jedem Info-GK o.ae. auch absolute Programmieranfaenger und darunter auch solche, die absolut nichts dazulernen.
Muss IMHO auch schwierig sein, dort alle beschaeftigt zu halten.

[dEUs]

Nobuo T schrieb:

dEUs schrieb:

Dann hab ich meinen Laptop mitgebracht und meinen Kram programmiert und Musik gehört. Ich war dann eigentlich nur noch für Fragen des Lehrers da, falls der was wissen musste Irgendwann war's mir dann zu doof und ich bin nicht mehr hin.

Nicht schlecht, nur was tun, wenn man noch kein eigenen Laptop hat.
Ich habe mir zumindest irgendwann dann mal einen SNES-Emulator runtergeladen und Chrono-Trigger gezoggd.
BTW: Gibt es bei euch nur freiwilligen Info-Unterricht?

In der 8. Klasse gibt's nen Pflichtkurs. Aber drüber gibt's garnix mehr, inzwischen nciht mal mehr nen freiwilligen. Auf LK-Niveau gab's auch nie was, weil die Lehrer dafür zu wenig drauf haben. Früher gab's in der 12. wohl sowas wie nen GK, gibt's inzwischen aber nicht mehr.
Aber SNES-Emu is doch auch ganz cool

Nobuo T schrieb:

dEUs schrieb:

Für Programmieranfänger war's meiner Meinung ok, aber sowas hat man bei uns auch schon in der 8. Klasse gemacht, deswegen hatte ich ein etwas höheres Niveau erwartet

Leider sind wohl in jedem Info-GK o.ae. auch absolute Programmieranfaenger und darunter auch solche, die absolut nichts dazulernen.
Muss IMHO auch schwierig sein, dort alle beschaeftigt zu halten.

Ja, klar. Aber da es nicht Pflicht war, hätten sie es ein wenig anspruchsvoller machen können, so dass die absoluten Anfänger (die eh nach n paar Wochen wieder verschwunden sind) garnicht erst gekommen wären und der Rest auf nem etwas höheren Niveau hätte unterrichtet werden können. Aber naja, bei dem Niveau, das für mcih echt noch interessant wäre, wäre das dann wohl Einzelunterricht für mcih gewesen, da sonst niemand mitgekommen wäre

[Alexander Sulfrian]

Hi,
also so wie ich das bis jetzt mitbekomme habe, machen wir den in der 12 (atm bin ich 11.) wieder weiter mit TurboPascal für Windows 1.0 (kann ich schon gut - hab sogar die WinCRT erweitert damit man Grafik bentuzen kann - war der Haupinformatiklehrer an unserer Schule ganz begeistert und hat nicht eine Funktion verstanden....), machen dann noch irgendwie Datenbanken und Prolog (aber der Hauptteil wir TP sein).

Naja und eigentlich sind alle Lehrer an unserer Schule inkompetent....
Sogar die Absicherung der PCs haben sie nicht ordentlich hinbekommen. Mann muss núr im Abgesicherten Modus neustarten und dann kann man sich ohne Passwort als Admin einloggen (WinXP) ....

MfG

Alexander Sulfrian

[EDIT]
Ach und nochwas: Immer wenn ich meiner Informatiklehrerin was von HTML erklären will, sagt sie nur, dass sie das schon immer so gemacht hat wie sie das jetzt macht und noch nie Probleme hatte. Aber sie meint, sie hätte noch nie eine Seite online gestellt und weiß nicht ob es dann Probleme gibt....

[Steven]

geeky schrieb:

Wir (Stufe 12, Info GK - LK gibts nich) fuckeln momentan mit Binärbaum, Suchbaum, Huffmannbaum und mittlerweile mit nem Termbaum rum...
...benutzt wird Delphi.

Warum machen wir das nicht? Bei uns gibt es nur UML, UML, UML... Bis zum Umfallen. Algorithmen wie Quicksort oder Baumstrukturen werden eigentlich gar nicht gelehrt. Der ganze IT-Unterricht ist dadurch auch sehr theoretisch, die Rechner werden so gut wie nie benutzt. (Wo ist eigentlich das *gähn* Smiley?) Dass solche Algorithmen gelehrt werden, finde ich um einiges wichtiger als dass man ein ganzes Jahr nur Rechtecke mit Linien verbindet, vor allem, da objektorientiertes Design ohne UML eigentlich leichter ist. Die Algorithmen entscheiden ja schließlich, ob und wie gut ein Programm funktioniert. Da hilft dann nur, sich solche Dinge selbst beizubringen...

[geeky]

Mit UML werden wir auch ständig gequält
Was mich nervt dass wir für jeden Schei** ne eigene Klasse machen sollen...

[Marc++us]

Steven schrieb:

vor allem, da objektorientiertes Design ohne UML eigentlich leichter ist. Die Algorithmen entscheiden ja schließlich, ob und wie gut ein Programm funktioniert.

Bitte erklären.

Es gibt sicherlich Alternativen zu UML, dennoch würde mich konkret interessieren was Du unter objektorientierem Design verstehst und wie Du dieses darstellst...

Abgesehen davon ist bei größeren Projekten das Design noch wichtiger als die Algorithmen, denn wenn das Design nicht stimmt, nützt der beste Algorithmus nix.

[SirLant]

Unsere IT-Lehrer sind so wie ich gehört habe alle nicht so die Experten, und vor
allem ist es furchtbar wie gut sich unserer mit der Sprache auskennt ständig
macht der was falsch weil ers einfach nicht kann und dabei hat er sogar nen
Buch zur Sprache

HTML-Programmierung haben wir auch, mit Frames

Dann kommen ab und an kluge Sätze, wie: "In der IT-Welt wird fast nur C++ eingesetzt,
Sprachen wie Delphi benutzt keiner wir nehmen Java auch nur weil es kostenlos ist
und man leicht auf C++ umsteigen kann."
Die Compiler von Borland und Microsoft kosten ja Geld

Könnt hier noch viel erzählen, aber das lassen wir besser, ich halt meist die klappe
und bekomm dafür ne gute Note und helf den Mitschülern

[Griffin]

Ich denke schon, dass Geld im Bezug auf Bildung inzwischen eine zu große Rolle spielt. Das macht sich halt gerade im Bereich Informatik bemerkbar, da gute Hardware und Software halt doch Geld kostet und man sich nicht immer das beste und aktuellste leisten kann. Vielleicht noch nicht einmal mit Förderungen vom Bildungministerium...Wir benutzen halt auch noch Delphi4 und für Java so einen blöden Klickbunti-Editor. Da würde mir aber eigentlich schon Notepad reichen

[Marc++us]

Griffin schrieb:

Das macht sich halt gerade im Bereich Informatik bemerkbar, da gute Hardware und Software halt doch Geld kostet und man sich nicht immer das beste und aktuellste leisten kann.

Das gilt auch für die Lehrer!

Die Guten sind vor 3-4 Jahren alle in die Industrie und haben ihre Jobs hingeschmissen.

[Steven]

Marc++us schrieb:

Steven schrieb:

vor allem, da objektorientiertes Design ohne UML eigentlich leichter ist. Die Algorithmen entscheiden ja schließlich, ob und wie gut ein Programm funktioniert.

Bitte erklären.

Natürlich mach ich mir bei größeren Projekten schon vorher Notizen, welche Klassen ich brauche und wie diese miteinander in Beziehung (Vererbung) stehen. Allerdings brauch ich dazu keine Formvorschriften a la UML. Das Design des Programmes ist am Ende sowieso ähnlich zum Entwurf mit UML, nur dass ich mir den Aufwand und die Zeit für die Zeichnerei spare.

Marc++us schrieb:

Abgesehen davon ist bei größeren Projekten das Design noch wichtiger als die Algorithmen, denn wenn das Design nicht stimmt, nützt der beste Algorithmus nix.

...andererseits nutzt mir ein Packprogramm, das nicht packt, natürlich auch nichts. :p
Im Ernst: Natürlich ist beides wichtig, aber bei uns werden die Algorithmen völlig vernachlässigt. Wenn unser IT-Lehrer eine Quicksort-Routine schreiben soll, fängt der wahrscheinlich erstmal an, ein Sequenzdiagramm dazu zu zeichnen...

[Griffin]

Marc++us schrieb:

Das gilt auch für die Lehrer!

Die Guten sind vor 3-4 Jahren alle in die Industrie und haben ihre Jobs hingeschmissen.

Hap, damit hast du natürlich ganz klar Recht! Es sollten regelmäßig Seminare oder Lehrgänge für sowas geben, da die Entwicklung auf dem Gebiet der Informatik auch sehr rasant voranschreitet. (wobei es diese Weiterbildung bestimmt gibt)

[Ruhollah]

Berichte über meinen Informatikunterricht dürfen nicht fehlen. Ich habe 2002 Abitur gemacht. 1999 hatten wir ein halbes Jahr Informatik in der Zehnten. Der Lehrer war lustig, aber Programmierung wurde nicht gemacht, sondern Textverarbeitung. Ich finde, dass Textverarbeitung wichtig ist, denn viele verwechseln eine Textverarbeitung mit einer Schreibmaschine und knallen ans Zeilenende jedesmal ein Absatz.

Im Schuljahr darauf gab es Informatik ganzjährig: Textverarbeitung, Tabellenkalkulation und Pascal. In Schuljahr 12 machten wir nur Pascal und gegen Ende spielten wir mit dBase III. Im letzten Schuljahr hat der Lehrer aber die Vogel abgeschossen: Das ganze Jahr über machten wir "Präsentation mit Powerpoint". Während ein anderer Kurs Prolog hämmerte, durften wir eine Präsentation über Onkel Pauls 80. Geburtstag machen und im anderen Semester eine Präsentation über ein selbstgewähltes Thema, in meinem Falle C++.

Die Bewertung der Präsentationen war auch total idiotisch. Es wurde gezählt, wie viele Animationen und Töne die Präsentation beinhaltete. Wer keine Animationen und keine Töne hatte, bekam null Punkte, obwohl Animationen und Töne in Präsentationen im richtigen Leben ungern gesehen/gehört werden. Animationen und Töne sind, wenn es zu viele sind, kontraproduktiv.

Die Kritik, Informatiklehrer müssten aufgrund der rasanten Entwicklung in der Informatik an Weiterbildungen teilnehmen, teile ich nicht. Der Informatikunterricht muss nicht auf der Höhe der Entwicklung sein, denn im Informatikunterricht müssen Grundkenntnisse vermittelt werden. Wichtige Sortieralgorithmen (Bubblesort, Quicksort, Mergesort usw.), Objektorientierung, Suchverfahren usw. gibt's doch schon seit geraumer Zeit. Die Grundkenntnisse gilt es zu vermitteln. Man muss auch nicht zig Programmiersprachen lernen, denn wenn man eine Programmiersprache kann, kann man auch alle ähnlichen Programmiersprachen. Der Einstieg erfolgt am besten mit Pascal; Pascal wurde von Niklaus Wirth allein wegen dem Lehraspekt so entwickelt. Will man Objektorientierung, kann man wenig Problemen auf Java oder C++ umsatteln. (Niklaus Wirth hat doch Modulo oder s. ä. entwickelt, eine Lehrsprache für die Objektorientierung; Modulo ist auch eine Möglichkeit.)

Was man überhaupt nicht im Informatikunterricht braucht, ist Delphi oder eine sonstige Entwicklungsumgebung. Ein freier Editor (Emacs!) und ein freier Übersetzer (davon gibt's reichlich) kosten nicht nur weniger, sondern man kann damit auch vernünftig lernen. Ich habe mal als Einsteiger die Erfahrung gemacht, dass Entwicklungsumgebungen wie Delphi einen geradezu erschlagen; man sieht den Wald vor lauter Bäumen nicht. Auch wenn solche Entwicklungsumgebungen aktueller Stand der Technik sind, so sind sie doch im Informatikunterricht ungeeignet.

Völlig fehlentwickelt ist ein Informatikunterricht an einer mir bekannten Privatschule; dort wird den Schülern Videoschnitt beigebracht. Es ist zum Glück nicht mein Geld.

In den Informatikunterricht gehören auch Grundkenntnisse in der Tabellenkalkulation und in der Textverarbeitung. Ich habe während eines Betriebspraktikums in einem Planungsbüro die Erfahrung gemacht, dass nicht jeder damit sinnvoll umgehen kann. Die Vize-Chefin (zugleich Tochter des Chefs) hatte in Excel eine Tabelle mit Preisen eingehämmert. Sie druckte die Tabelle aus und meine Aufgabe war es, zu überprüfen, ob die Summe am Ende auch stimmte. Die Summe wich von der tatsächlichen Summe geringfügig ab. Die Frau hatte doch tatsächlich die Zahlen eingehämmert, aber nicht die Summe über die Summenfunktion errechnet, sondern die Summe vor dem Bildschirm mit dem Taschenrechner errechnet und unter die Zahlenreihe getippt. Man muss sich mal klar werden, was das für die Produktivität und Volkswirtschaft bedeutet, wenn in vielen Büros dieser Republik eine solche Unkenntnis herrscht. Es wird zusätzlich noch Kapital verschwendet, wenn man gutes Geld für Excel ausgibt, aber sich nicht einmal der Grundfunktionen Excels bedient. Bei der Bundeswehr bat mich eine Beamtin von der StOV, ihr ein bisschen bei Excel zu helfen. Sie wusste nicht mal, was Kopf- und Fußzeilen sind. Man muss sich mal bewusst werden, wieviel Kapital auch beim Staat wegen mangelnden Grundkenntnissen in der Informationsverarbeitung verschleudert wird; beim Staat ist Verschwendung aber nichts neues. Die Beamtin hätte sich mal lieber in Excel richtig einfuchsen sollen, dann hätte sie auch mehr Zeit gehabt, mit ihrem Lieblingskasernenfeldwebel Kaffee zu trinken.

[Ranus.net]

hu

habe das jetzt zwar net durchgelesen - aber - hey !
sei doch froh ... unsere könnte das gar net *fg*....

wir machen so nen scheiss in delphi (das heißt - sie erzählt was - schreibts an die tafel - oder per beamer an die wand - wir schreiben ab - bei wem das net klappt - pech gehabt - helfen kann sie auch net - wenn jemand ne frage hat - öööhm - fragt sie einen von uns der mehr ahnung davon hat .. *omg*)

sorry - aber sowas infolehrerin ^^

bye bye

[volkard]

Marc++us schrieb:

Steven schrieb:

vor allem, da objektorientiertes Design ohne UML
eigentlich leichter ist. Die Algorithmen entscheiden ja schließlich, ob und wie gut
ein Programm funktioniert.

Bitte erklären.
Es gibt sicherlich Alternativen zu UML, dennoch würde mich konkret interessieren was
Du unter objektorientierem Design verstehst und wie Du dieses darstellst...
Abgesehen davon ist bei größeren Projekten das Design noch wichtiger als die Algorithmen,
denn wenn das Design nicht stimmt, nützt der beste Algorithmus nix.

(ausnahmsweise ein paar grossbuchstaben wegen der historischen bedeutung)

Sag mal, Marc++us, malst du die Algos, die du erfasst, vorher auf Papier?
So, wie damals vor 20 Jahren die strukto-Heinis lehrten und die IHK noch heute?
Das war schon immer und ist noch heute der falsche Weg. Man darf nicht die Algos
hinmalen, um sie zu verstehen. Man muß die Daten malen. Bäumchen, Listchen, Arrays und
so malt man und an denen probt man den im Kopf estehenden Algo und verfeinert und
beginnt ihn zu kapieren. Statt des Malens kann man oft noch besser Karten auslegen,
Münzstapel bauen usw.. Die langsam wachsenden Teile darf man gleich einhacken.
Dabei lernt man auch, wie sich der Algo auf der Maschine anfühlt, evtl ist er ja Mist
und man sollte über nen neuen nachdenken. Und wie er sich auf der Maschine anfühlt,
bestimmt, wie er im weiteren implementiert wird! Bestimmt sogar, für welche
Datenstrukturen man sich entscheidet und darüber wieder Teile des Algos oder ihn ganz.

Ohoh, der sündige Begriff kommt. "explorativ programmieren"!

Ja, so macht man es. Ich stehe dazu. Mein Prof stand dazu. Und es ist der einzige
vernünftige stil. Nicht nur, daß man in halbdokumentierten Welten wie der winapi
gar nicht anders kann, es ist auch die natürliche Herangehensweise und der erzeugte
Code ist regelmäßig erheblich besser, als bei vorhergemalten Programmen.

Ja, ich lernte damals, daß ungeplante Programme regelmäßig ganz schlecht seien. Ja, da
ist gar kein Widerspruch. Der erste Entwurf ist immer schlecht. Aber den verbessert man
ja dann. Welchen Nutzen kann es haben, zuerst ne Weile auf Papier zu verbessern, dann
willkürich auf Code zu wechseln und dann im Code weiter zu verbessern? Keinen. So
planten die Planer das ja auch nicht. Die planten, daß man auf Papier verbessert und dann
nach Code übersetzt und fertig. Und nach der Codierung die Sintflut. Das ist doch
offensichtlich Write-Only-Vorgehen.

Struktogramme sind schädlich und verschlechtern den entstehenden Code!

Es fragt sich, warum sich diese Irrlehre mit den Struktogrammen so lange gehalten hat.
Hat man auf "goto considered harmfull" von Dijkstra einfach schrecklich überreagiert?
Oder gibt es ein allinformatorisches Prinzip, das besagt, daß stets die Wirtschaftler
mit der wenigsten EDV-Ahnung die Vorgehensweisen erzwingen können? Ich kann es leider
nicht nachvollzehen, da ich nie an Struktogramme glaubte.

Das Urteil bezieht sich natürlich nicht nur auf Struktogramme, sondern auch auf Konsorten.

Um so erschreckender ist es, daß man heute mit UML den gleichen Fehler macht, wie damals.
(Und mit Konsorten.)
Jetzt sind es nicht mehr die Algos, die das Programm bestimmen, sondern die Klassen.
Es waren im übrigen nie die Algo-Verflechtungen und auch nie die Klassenverfelchtungen.
Man malt die Klassen in völlig wurstigen Diagrammen hin, die angenommen, man macht sie
vorher, das Programm blockieren. Aber die UML-Heinis von heute sind die Strukto-Heinis
von gestern. Sie lehren, man solle UML hier und UML da malen. Die IHK steigt nach UML um
und prüft jetzt UML ab aber keinen Code. So, als könne man damit ein Programm beschreiben.

[quote="Marc++us"]dennoch würde mich konkret interessieren was Du unter
objektorientierem Design verstehst und wie Du dieses darstellst[quote]
Man kann gutes OO-Design nicht darstellen. Mit UML-Klassenstrukturdiagrammen malt man
nen Vererbungsbaum und ein wenig Käse dazu.

class KFZ
{
  double x,y,z;//in millimeter
  double gewicht;//in gramm
  string halter;
  ...
};
class PKW:public KFZ
{
  int anzahlSitzplaetze;
  ...
};
//UIHUIHUIH, ist dieser Entwurf grottenschlecht!
//Aber man sieht es nicht direkt und auf dem Bildchen genausowenig direkt!

(Ich hoffe, du vertraust mir, daß ich gutes OO-Design hinkriege und normaerweise nicht
wie oben alle zwei Zeilen einen Fehler mache (sie aber in fremdem Code sehe). Gerade
deswegen darf ich das Maul aufreißen und sagen, daß Bildchen störend sind.)

Und dazu male man mal ein Bildchen. Ohoh, das Bildchen sagt nicht mehr und nicht weniger
aus. Wozu also malt man die Bildchen? Doch nur, um zu reduzieren! Ich aber kenne den
textuellen Redukator "...". Damit klappt das auch.

Ich hoffe, wir sind uns einig darüber, daß man in UML nicht planen darf. Tut man's, kriegt
man sofort suboptimalen Code. Willst Du den zweitbesten einstellen? Wohl eher den besten.
Aber er soll zweitbesten Code bauen? Da paßt doch was nicht.

Und wem gegenüber wird dokumentiert? Leuten gegenüber, die C++ flüssig lesen können?
Die arbeiten lieber mit Pseudocode.

UML hat allein die Berechtigung, damit den Chef zu belästigen! Wenn er UML haben will, dann
kriegt er's. Aber UML hat nix und überhaupt nix in der Entwicklung zu suchen. Entsprechend
soll man UML erst malen, wenn das Prog ausgeliefert wurde. Und jede
Lehre von UML in Schule und Berufsschule ist schlichte Zeitverschwendung. Zum Glück
haben die Kids dahingehend ein sicheres Gefühl und lehnen den Kram von selber ab.
Es besteht also erstmal nur geringe Gefahr, die Kids sogar zu verderben (Struktogramme
waren gefährlicher und UN war direkt infektiös).

Warum fallt ihr immer auf solche Zeitgeister herein, statt normal zu coden? Was ist das
für ein Geheimnis, das sich mir nicht erschließen mag?

Und unabhängig davon, ob jemand mir dies beantworten kann oder mag: Hört endlich mit
UML auf. Hört da mal auf mich, ihr werdet in zehn oder fünfzehn Jahren, wenn die
Mehrheit es einsieht, es mir danken.

[volkard]

Steven schrieb:

Natürlich mach ich mir bei größeren Projekten schon vorher Notizen, welche Klassen ich brauche und wie diese miteinander in Beziehung (Vererbung) stehen. Allerdings brauch ich dazu keine Formvorschriften a la UML. Das Design des Programmes ist am Ende sowieso ähnlich zum Entwurf mit UML, nur dass ich mir den Aufwand und die Zeit für die Zeichnerei spare.

Aha, sie haben dich schon gefickt!
Die Formvorschriften lehnste ab, aber willst schon den "Entwurf" vorher notieren, nur lockerer.
TU ES NICHT!

[Marc++us]

Volkard, Du bist gerade an meiner Ausfahrt vorbei gerast.

Mir ist die Notation grundsätzlich egal - UML, Pseudocode, oder C++ mit [...].

Die Idee dahinter ist aber immer gleich - eine abstraktere Ebene oberhalb des Codes. Viel zu viele Leute fangen aber gleich mit dem Code an und "spiralen" sich dann Richtung fertiges Programm.

Das mag angehen, wenn ein Entwickler für alles alleine verantwortlich ist, weil er die Abstraktionsebene im Kopf hat. Bei Teams mit mehr als zwei Personen ist aber eine Absprache von groben Entwürfen notwendig. Und dazu wird man irgendeinen Formalismus wählen, der kaum bereits auf Codeebene liegt.

Hacken alle Leute selbständig darauf los und explorieren ihren Code, passt hinterher vielleicht die Mutter nicht mehr auf das Gewinde. Bei Toll-Collect haben sie hinterher Module zusammenfügen wollen, bei denen die Datenschnittstellen nicht übereinstimmten. Da wäre irgendwann ein Bildchen vielleicht sinnvoll gewesen, bevor man an 2 getrennten Entwicklungsorten mit der Codierung beginnt.

Ich unterstelle folgendes Modell: n Entwickler (n > 1) unterhalten sich über ein Softwareprojekt. Dazu bedienen sie sich einer Sprache mit gemeinsamen Zeichenvorrat. Je weniger gut sich die Leute kennen, desto weniger gut kann man eine nicht-standardisierte Sprache dafür verwenden. Weiterhin darf's nicht zu genau werden, man will ja noch nicht coden. UML (aber nur die 1.x... 2.0 ist "bißchen" zu detailiert geraten) ist dafür gar nicht so schlecht. Nicht ideal, aber auch nicht schlecht.

So, nun mache ich einen umgekehrten Induktionsschluß und nehme an, daß auch ein Einzelentwickler (Teamgröße n = 1) so arbeitet - er kommuniziert mit sich selbst genauso über eine Abstraktionsebene. Natürlich völlig unnötig, da man diese Stufe vereinfachen kann. Aber wenn ich will, daß diese Person irgendwann mal im Team arbeitet, benötige ich diese Abstraktionsebene - damit diese Person eben über die notwendige Schnittstelle verfügt.

Netter Nebeneffekt ist, daß man Lehrnende auch mal zwingt, sich von ihrer gottverdammten Programmiersprache zu lösen und mal das Problem abstrakt zu durchdenken.

Abgesehen davon kann man Indern mit UML total toll erklären.

[Steven]

@volkard: Dein langer Artikel spricht mir aus der Seele!

volkard schrieb:

Steven schrieb:

Natürlich mach ich mir bei größeren Projekten schon vorher Notizen, welche Klassen ich brauche und wie diese miteinander in Beziehung (Vererbung) stehen. Allerdings brauch ich dazu keine Formvorschriften a la UML. Das Design des Programmes ist am Ende sowieso ähnlich zum Entwurf mit UML, nur dass ich mir den Aufwand und die Zeit für die Zeichnerei spare.

Aha, sie haben dich schon gefickt!
Die Formvorschriften lehnste ab, aber willst schon den "Entwurf" vorher notieren, nur lockerer.
TU ES NICHT!

Nein, ich habe mich nur unglücklich ausgedrückt: Bei großen Projekten mit mehr als ca. 6-8 Klassen schreibe ich mir auf, welche Klassen ich brauche und welche Klasse von welcher erbt. Viel mehr ist das eigentlich nicht. Für kleine Projekte habe ich das auch noch nie gemacht.

Man muß die Daten malen. Bäumchen, Listchen, Arrays und
so malt man und an denen probt man den im Kopf estehenden Algo und verfeinert und
beginnt ihn zu kapieren. Statt des Malens kann man oft noch besser Karten auslegen,
Münzstapel bauen usw.. Die langsam wachsenden Teile darf man gleich einhacken.
Dabei lernt man auch, wie sich der Algo auf der Maschine anfühlt, evtl ist er ja Mist
und man sollte über nen neuen nachdenken. Und wie er sich auf der Maschine anfühlt,
bestimmt, wie er im weiteren implementiert wird! Bestimmt sogar, für welche
Datenstrukturen man sich entscheidet und darüber wieder Teile des Algos oder ihn ganz.

So mach ich das auch, wenn ich neue Algorithmen entwerfe oder versuche zu verstehen. Klappt eigentlich auch immer ganz gut...

Welchen Nutzen kann es haben, zuerst ne Weile auf Papier zu verbessern, dann
willkürich auf Code zu wechseln und dann im Code weiter zu verbessern?

Meine Rede!

Struktogramme sind schädlich und verschlechtern den entstehenden Code!

Es fragt sich, warum sich diese Irrlehre mit den Struktogrammen so lange gehalten hat.
Hat man auf "goto considered harmfull" von Dijkstra einfach schrecklich überreagiert?
Oder gibt es ein allinformatorisches Prinzip, das besagt, daß stets die Wirtschaftler
mit der wenigsten EDV-Ahnung die Vorgehensweisen erzwingen können? Ich kann es leider
nicht nachvollzehen, da ich nie an Struktogramme glaubte.

Goto macht den Code sogar in manchen Fällen lesbarer, nämlich, wenn man aus mehrfach verschachtelten Schleifen raus will.

Aber die UML-Heinis von heute sind die Strukto-Heinis
von gestern. Sie lehren, man solle UML hier und UML da malen.

Und so einen haben wir als IT-Lehrer...

BTW: Ich wäre mal dafür, diese Grundsatzdiskussion in einen eigenen Thread zu verschieben...