PAMKKKKK hat geschrieben:Erstmal ein dickes DANKE für dein Feedback und die Konstruktive Kritrik
Büddeschön. Hast wirklich Lob für Deine Mühe verdient
PAMKKKKK hat geschrieben:
Ist in meinem Kopf fest eingeplant.
(Gibt es ja auch schon ein Buch drüber, wenn auch in Englisch
2-D Scroll-Spiele Programmieren
http://www.codersworkshop.com/viewproduct.php?id=22 )
Habs schon bestellt...und werde es übersetzen
Das ist das Ding von "Krylar",oder? Ist ziemlich gut, hab die "Vorversion", die er mal für BlitzBasic geschrieben hat.
Aber dem steht ja nicht entgegen, dass Arrays und "LiLi"s ggf. gemeinsam behandelt werden können, oder?
PAMKKKKK hat geschrieben:
JaEin !!!
LiLis (geile Abkürzung), sind leicht zu benutzen. ABER:
Mein Ausbilder (Modelltischler) hat immer gesagt:
"Wenn du weißt wie eine Maschine Funktioniert, dann kannst du dich auch nicht dran verletzen!"
Wen man nun LiLis erklären will, muss ich die Interna von doppeltverketteten Listen erklären und das ist Structure und Pointer kram….
So habe ich gedacht!
P.S. Ich habe dazu schon ein Bild gemalt, guck mal hier ….
http://www.purearea.net/pb/english/pure ... nked_Lists
Naja, wenn man von C her kommt (habe den Verdacht, dass Dir diese Sprache auch nicht unbekannt ist

) hast Du recht, weil es dorten ja keinen eigenen Datentyp dafür gibt. In PB gibt es den glücklicherweise, und die entsprechenden Befehle zur Verwaltung sind auch schon da, d.h., - um bei Deinem Bild zu verharren - der Neuling hat bereits "die fertige Handstichsäge" und muss nicht erst "die Bohrmaschine holen, dann das Bohrfutter abnehmen, die Achse in den Stichsägenaufsatz einpassen, letzteren festschrauben, das Sägeblatt einsetzen un befestigen " und kann dann endlich anfangen.

))
Ich habe wieder aus Anfängersicht gedacht, und der Gedankengang war, den Anfänger zunächst an Arrays heranzuführen, ihm dann die Probleme, die aus dem starren Konzept "Array" erwachsen (etwa: "Einfügen mitten in ein gefülltes Array", "Bestimmen des letzten _gefüllten_ Elements" etc., etc.), zu schildern und dann zu LiLis zu führen, die genau in der Beziehung "easy" sind.
Und DADRAUF kann man später die "inner workings " setzen, mit Pointern, structures etc., sozusagen als Krönungstheorie ("und jetzt zeigen wir Dir, wie es unter der Haube aussieht"). Das ist vielleicht sogar ein ganz guter praktischer Aufhänger, um überhaupt klarzumachen, warum man sich als Programmierer mit Pointern abgeben sollte (klar, es gibt natürlich auch andere gute Aufhänger).
Dein Bild gefällt mir gut, ich hatte mir auch was überlegt, war aber bei verbundenen Lastkähnen oder Eisenbahnzügen angelangt. Die Elefanten sind vielleicht flexibler;)
Ich halte das GUI-Zeug für das Lernen der Grundlagen, wirklich für sehr hinderlich am Anfang!!!!!!
Ich halte es für
etwas hinderlich, aber es ereilt den Neuling ja sowieso kurz darauf, wenn sich das Consolenkonzept sicher auch noch nicht völlig bei ihm gesetzt hat.
Das führt dann zu zusätzlicher Verunsicherung, letztlich damit zu erhöhtem Erklärungsbedarf; das Nachfragen oder Gedankenmachen sollte sich aber vorteilhafter nicht "out-of-band" abspielen (sprich: der Neuling sollte besser
darüber nachdenken, warum seine while-wend Schleife einmal zu kurz greift, als dass er sich wundert, warum das, was er doch gestern noch super auf der Console ausgegeben bekommen hat, heute im Window ums Verrecken nicht angezeigt werden will,
obwohl er's doch 1:1 übertragen hat 
. Letzters kann einem wirklich den ganzen Tag verderben, vor allem in der Lernphase)
"Wenn du weißt wie die Grundlagen einer Maschine Funktionieren, dann kannst du auch schneller eigene Maschinen entwickeln!"
Gegen den Satz kann man nix sagen, der behält seine Richtigkeit aber eben auch, wenn man das bischen "Windows" -Framework, das bei PB noch erforderlich ist, um die Ergebnisse der ersten Versuche mit Programmlogik zu präsentieren, von Anfang an mit angeht. Ich sag'ja nicht, dass man sofort mit Callbacks, Gadgets und Eventsteuerung anfangen soll.
Aber warum nicht 'nen messagerequester anwerfen statt 'nemPrintN, um Ergebnisse anzuzeigen ?
Da ich auch bei den Programmierbüchern immer sehr ungeduldig lese (ich will nicht voll gequatscht werden, sondern schnell mal Far Cry Programmieren!

)
Kenne ich !

)
versuche ich das mit Konsolenspielen wieder auszugleichen und möglichst schnell zu GUI über zu gehen.
Hmmm... interpretiere ich den Satz jetzt richtig, wenn ich annehme:jetzt sprichst Du von Dir persönlich, nicht von dem, was Du mit dem Buch vorhast? Denn genau dieser "schnelle Übergang" zur GUI wäre dann das, was den Frischling irritiert.
Das langsame Gründliche erklären, war mir wichtiger als quick ´n dirty
Ja, völlig d'accord, aber es führt ja kein "natürlicher" Weg von der Console- zur Gui Anwendung. Insofern ist der direkte Einstieg in die windows-Umgebung nur unwesentlich quicker, aber schon gar nicht "dirty".
Ich meine auch nicht, dass Console_Anwendungen völlig unerwähnt bleiben sollen, bin aber der Ansicht, dass man die als eine Art Exkurs nachreichen sollte ( wenn einer heute den Führerschein macht, wird er auch erstmal den Eindruck bekommen, dass OHNE ABS, 8 Airbags, Servolenkung , Bremsservo, Einparkassistent, Klimaanlage Autofahren undenkbar ist. Gib ihm dann mal eine AlfaRomeo
aus den 70er Jahren (hmm. die sind alle weggerostet.Sagen wir also gleich: einen Porsche aus den 70er Jahren

) und lass ihn mal damit fahren. Er wird bei der Fahrt einen Höllenspass haben. Aber ob er mit dem alten Wagen - den Effekt auf geneigte Mädels lassen wir hier unbetrachtet

- aber jeden Tag zur Arbeit oder Uni fahren will ?)
Auch d'accord, aber es ist eben ein Online Buch, d.h., die Grenze zum Tut. wird sehr verschwimmen; ist m.E. auch gewollt und gut so. Online Bücher werden IMHO auch sicher nicht auf diesgleiche Art wie materielle Bücher gelesen.