Informatiklehrer

[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...

[volkard]

Steven schrieb:

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.

ich empfehle es auch für 100 klassen nicht. die klasse leuchtet aus sich selbst heraus und ist rund und gut. sie lebt nicht erst im verband mit anderen klassen.

[quote="Steven"]Goto macht den Code sogar in manchen Fällen lesbarer, nämlich, wenn man aus mehrfach verschachtelten Schleifen raus will.[quote]
aber da will man nicht mt goto raus, da man die mehrfach verschachtelen schleifen in ne funktion ausgelagert hat, und aus den schleifen hüpft dort ein return.

[volkard]

Marc++us schrieb:

Volkard, Du bist gerade an meiner Ausfahrt vorbei gerast.

nicht wirklich, fürchte ich.

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.

kann es sein, daß ich den befähigten coder unterstelle und du davon ausgehst, mit luschen zu arbeiten?

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.

und schädlich!

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.

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?

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

nope! eine gottverdammte maschine hat drunter zu sein. und man kann in uml nicht denken. eckmarken und stolperfallen des schlechten entwurfs äußern sich immer darin, daß man letztendlich im coden und warten ein fieses problem kriegt. wie will man dafür ein verständnis aufbauen, wen man abstrakte bildchen malt?

edit: streich am besten selbst alle argumente für UML, die mit gleichem wortlaut auch für struktogramme oder für UN sprecvhen würden.

[SirLant]

Hm, also ich hab bisher meist drauf losgeschrieben, weil ich ungefähr im Kopf
wusste wie ich es angehe, mein Nachteil ist, dass das Design ganz von meiner
Laune, Müdigkeit und anderen Einflüssen abhängt, kann man natürlich nachträglich
noch ändern, aber wozu wenn man es mehr zu Spass geschrieben hat

Meine Notizen, wenn ich etwas plane sehen so aus:
-Ich schreib mir auf was ich machen möchte, entwerfe erste Ideen für das Datendesign
-Überlege mir was ich brauche um damit zu arbeiten, dann ändere ich das Datendesign
höchstwarscheinlich, weil man es einfach noch besser machen kann
-Entwerfe ein Klassendesign wo das ganze reinkommt, das ist einfach auf nem Papier:

foo public: bar {
// öffentliche Schnittstellen
// Datenmembers
};

Die Verbindung der Klassen, kann man doch ganz einfach darstellen indem man ein
Blatt nimm die Namen hinschreibt und je nach Art der Beziehung die Linie in ner
anderen Farbe malt. Schnittstellen sind hier doch uninterressant.
Nen Algo entwickle ich eigentlich meist außerhalb und schmiere den erstmal so hin,
versuche zu verbessern und schreibe ihn am schluss nochmal schön (formatierung,
Namen,...) teste ihn nochmal und bau ihn ein.

[Marc++us]

volkard schrieb:

kann es sein, daß ich den befähigten coder unterstelle und du davon ausgehst, mit luschen zu arbeiten?

Ich unterstelle den real verfügbaren Entwickler.

Mein Problem ist: die Leute hören die Problemstellung, schalten den PC an, starten die IDE, und beginnen zu tippen. Wenn's gut läuft, gleich mit der GUI anfangen. "Gerechnet wird noch nix, aber die Dialoge habe ich schon fertig"

Ich versuche hier irgendwie den Zwischenschritt "Nachdenken" einzubauen. Bisher gelang das nur, wenn man die Leute zwingt den PC mal 4 Stunden aus zu lassen und auf Papier ihre Idee zu skizzieren. Sobald der PC an ist, entwickeln sich die meisten Leute zu brachialen Trial&Error-Codern, die bereits eine Schleife auf Assemblerebene optimieren, aber noch keine Bereichsprüfung im Algorithmus drin haben.

Nur wenige sind in der Lage, aus dem Problem ein Gebilde zu entwerfen und das im Kopf zu haben, und dieses in Code umzusetzen. Also erzwinge ich die Visualisierung des Gebildes.

Den Unterschied Struktogramm - UML sehe ich darin, daß man Struktogramme auf einer Ebene einsetzt, die sich auch schwache Entwickler noch vorstellen können, daher redundant sind. Aber nur wenige können sich auch noch die gesamte Applikation im Zusammenspiel vorstellen.

[volkard]

Marc++us schrieb:

Mein Problem ist: die Leute hören die Problemstellung, schalten den PC an, starten die IDE, und beginnen zu tippen.

das ist gut.

Wenn's gut läuft, gleich mit der GUI anfangen. "Gerechnet wird noch nix, aber die Dialoge habe ich schon fertig"

das ist schlecht.

Ich versuche hier irgendwie den Zwischenschritt "Nachdenken" einzubauen.

das ist schlecht.
nachdenken muß nicht *ein* zwischenschritt mal sein, sondern immer dabei sein. sofort nach dem starten der ide bis ans späte ende, wenn die gui gestrickt wird.

Bisher gelang das nur, wenn man die Leute zwingt den PC mal 4 Stunden aus zu lassen und auf Papier ihre Idee zu skizzieren.

und danach plattes einhacken.

Sobald der PC an ist, entwickeln sich die meisten Leute zu brachialen Trial&Error-Codern, die bereits eine Schleife auf Assemblerebene optimieren, aber noch keine Bereichsprüfung im Algorithmus drin haben.

evtl solltest du den leuten beibringen, daß jede funktion und jede klasse in der ersten version schrott ist und eh reimlementiert weden soll? daß es ausnahmen gibt, und manch eine funktion auch mal auf anhieb kein designfehler ist, werden sie selber bemerken.

Nur wenige sind in der Lage, aus dem Problem ein Gebilde zu entwerfen und das im Kopf zu haben, und dieses in Code umzusetzen. Also erzwinge ich die Visualisierung des Gebildes.

ich habe eigentlch immer sehr früh das gebilde im kopf. so nen roten faden, an dem sich entlangzuhangeln lohnt. aber nie so, daß man es bereits verwerten könnte. und ich mische stats top-down mit bottom-up. vorher malen wäre echte zeitverschwendung. aber ich würde eh kündigen, wenn mein chef solchen blödsinn von mir verlangte.

Aber nur wenige können sich auch noch die gesamte Applikation im Zusammenspiel vorstellen.

die klasse lebt aus sich heraus, nicht aus dem kontext. wie drüben der FileExplorer http://forum.c-plusplus.net/viewtopic.php?t=73335&highlight= , der lebt einfach so, es ist brauchbar. egal, wer ihn warum benutzt.
es ist unfug, sich die ganze applikation im zusammenspiel vorzustellen. es war in der rein prozeduralen zeit auch schon unfug, diese aufruf-diagramme zu malen, wo man entnehmen kann, welche funktionen welche funktionen aufrufen. hat die funktion *einen* zweck und einen guten namen, lebt sie allein gut.