Gruselige FOR-Schleifen

Es gibt 165 Antworten in diesem Thema, welches 17.722 mal aufgerufen wurde. Der letzte Beitrag (11. Juni 2022 um 02:54) ist von oobdoo.

  • Omega 49152/$C000 liegt außerhalb des von BASIC V2 benutzten Speichers.

    oobdoo RENUMBER war bei so ziemlich allen Erweiterungen wie z.B. dem FC3 dabei, und ohne sowas hat wohl kaum jemand seinen C64 betrieben. Abseits davon: Z.B. Gold Quest 6 wurde ohne einen einzigen RENUMBER-Durchlauf geschrieben, geht also, wenn auch manchmal etwas nervig.

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • So simpel wie in BASIC programmiert sich ein Spiel mit ein paar PETSCII-Grafiken sonst nirgends

    Einspruch. :prof:

    Sowas geht natürlich auch auf dem CPC. Neue Zeichen definieren ist durch einen eigenen Befehl total einfach zu machen. Selbst das pixelgenaue Positionieren ist in BASIC ohne Tricks möglich.

    Was ich mir unter V2 BASIC schwer vorstelle ist das Programmieren ohne RENAME zum umdefinieren von Zeilennummern. Auch das ist beim CPC möglich.

    Einspruch stattgegeben.

    Soweit ich mich erinnern kann, hatte das Locomotive Basic auf dem 464 einen eigenen grafischen Zeichensatz.

    La vida es hoy !

    Schöne Grüße vom größten Kanalknotenpunkt der Welt.

  • In den 90'ern wurde in der 64'er ein spezieller Editor für BASIC-Programme veröffentlicht. Wimre war das keine BASIC-Erweiterung wie z.B. Simons' Basic oder Paradoxon Basic. Was genau damit alles möglich ist, weiß ich nicht mehr. Auch den Namen leider nicht. Mir ist jedoch in Erinnerung geblieben, dass dort keine Zeilennummern verwendet wurden, aber Labels.

    Es ist der BASIC-Assembler aus Bitte melde dich an, um diesen Link zu sehen..

  • Die "zeilenbasierte" Denkweise ist aber schon wesentlich bei BASIC V2 (also das ewige "ich muss meinen THEN-Code kurz halten, sodass er in 80 Zeichen passt"), und die ist zum Glück ausgestorben.

    Da gibt es bei den höheren Programmiersprachen sehr unterschiedliche Coding-Styles. Die einen schreiben z.B. grundsätzlich

    if () {

    cmd;

    }

    andere bevoprzugen das kompakte

    if () cmd;

    Aber wenn man im Team mit Versionskontrollsystemen arbeitet, dann sind die Formatierung und andere Coding-Styles sowieso meistens strikt vorgegeben. Der Quellcode wird dann beim Speicheren grundsätzlich komplett durchformatiert. Da hat man überhaupt keine Wahl. Verstöße gegen Coding-Styles kann man oft gar nicht ins Versionssystem einchecken.

    Bitte melde dich an, um diesen Link zu sehen.

    Einmal editiert, zuletzt von detlef (7. Juni 2022 um 15:42)

  • Nichts, aber auch gar nichts von dem, was man sich bei der Basic-Programmierung angewöhnt hat, findet sich in modernen Programmiersprachen und Frameworks wieder.

    Ein paar Sachen sind ja noch geblieben. Spontan fallen mir da ein: IF...THEN, FOR...NEXT, RND, LEFT, RIGHT, MID, DIM, STR, ASC, CHR.

    Das hat zwar die Herangehensweise nicht wirklich bis heute beeinflusst. Aber da fühlt man sich doch gleich wie zuhause. :rolleyes:

    Wobei FOR...NEXT immer mehr durch Collection-Operationen mit Lambda-Ausdrücken ersetzt werden (zum Beispiel map in Javascript). Das klassische FOR() oder FOREACH() braucht man immer weniger. Die String-Operationen gibt es in dieser Form natürlich nicht mehr, da man mit String-Klassen arbeitet. Statt dem ganzen right, left, mid-Gedönse hat man in der Regel eine substring-Methode.

    Also unterm Strich bleibt davon auch nicht viel übrig.

    Bitte melde dich an, um diesen Link zu sehen.

    2 Mal editiert, zuletzt von detlef (7. Juni 2022 um 15:42)

  • Statt dem ganzen right, left, mid-Gedönse hat man in der Regel eine substring-Methode.

    ...oder in manchen Sprachen entsprechende Operatoren, z.B. in Python [3:7] um einen Substring vom 3. bis 7. Zeichen zu erhalten, oder [3:] vom 3. bis Ende, oder [:7] bis zum 7. Zeichen, etc.

    (das ganze funktioniert natuerlich auch bei Listen, ist also dasselbe Prinzip)

    - neue Spiele für den C64 -
    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.

  • Statt dem ganzen right, left, mid-Gedönse hat man in der Regel eine substring-Methode.

    ...oder in manchen Sprachen entsprechende Operatoren, z.B. in Python [3:7] um einen Substring vom 3. bis 7. Zeichen zu erhalten, oder [3:] vom 3. bis Ende, oder [:7] bis zum 7. Zeichen, etc.

    An den Methoden gefällt mir, dass ich sie überladen kann um zum Beispiel zusätzliche Prüfungen einzubauen. C# schmeisst mir nämlich immer irgendwelche lässtigen Exceptions, wenn ich über das Stringende hinaus arbeite. In vielen Fällen ist mir das aber wurscht und dann sollen die Stringfunktionen einfach mit dem arbeiten was da ist.

  • Statt dem ganzen right, left, mid-Gedönse hat man in der Regel eine substring-Methode.

    ...oder in manchen Sprachen entsprechende Operatoren, z.B. in Python [3:7] um einen Substring vom 3. bis 7. Zeichen zu erhalten, oder [3:] vom 3. bis Ende, oder [:7] bis zum 7. Zeichen, etc.

    An den Methoden gefällt mir, dass ich sie überladen kann um zum Beispiel zusätzliche Prüfungen einzubauen. C# schmeisst mir nämlich immer irgendwelche lässtigen Exceptions, wenn ich über das Stringende hinaus arbeite. In vielen Fällen ist mir das aber wurscht und dann sollen die Stringfunktionen einfach mit dem arbeiten was da ist.

    Operatoren lassen sich in einigen Sprachen auch ueberladen ;)

    Aber wenn man eine Funktion baut, die etwas anderes tut als erwartet, dann wuerde ich persoenlich eher einen eigenen Namen waehlen oder eine eigene Klasse bauen, da es eigentlich sehr unschoen ist, Operatoren oder gaengige Funktionen durch eigene Implementierungen zu ersetzen, in denen einem etwas "wurscht" ist :)

    - neue Spiele für den C64 -
    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.

  • Wobei FOR...NEXT immer mehr durch Collection-Operationen mit Lampda-Ausdrücken ersetzt werden (zum Beispiel map in Javascript). Das klassische FOR() oder FOREACH() braucht man immer weniger. Die String-Operationen gibt es in dieser Form natürlich nicht mehr, da man mit String-Klassen arbeitet. Statt dem ganzen right, left, mid-Gedönse hat man in der Regel eine substring-Methode.

    Also von der Organisation her stimmt ich zu.

    Aber inhaltlich sind die Schleifen und Befehle ja nicht weg, sondern woanders.

    Und dann ist das noch die "Gewöhnung" bzw. die "Denke", die ja ein Hauptthema ist:
    Wenn ich irgendwo innerhalb einer Aufgabe die Summe aller Elemente brauche, dann denke ich FOREACH. Und weil man mit einer Foreach-Variablen nicht alles machen kann, wird wieder FOR NEXT draus.

    Ich denke nicht an einen Foreach-Ersatz mit Lambda, und ich denke nicht an eine Klasse, die die Summe ihrer Elemente zur Verfügung stellt.

    Beim Lambda sehe ich beim konkreten Anlass keinen Vorteil, und sofort eine Klasse machen ist erstmal auch mehr Aufwand als ein Einzeiler zum Bilden der Summe.

    Die Klasse hat Vorteile, und so nach und nach greife ich als Noob auch eher dazu, aber sie stört zuerst mal meinen Denkfluss.

    C# schmeisst mir nämlich immer irgendwelche lässtigen Exceptions, wenn ich über das Stringende hinaus arbeite. In vielen Fällen ist mir das aber wurscht und dann sollen die Stringfunktionen einfach mit dem arbeiten was da ist.

    Ich weiß nicht, ob das so im Sinne des Erfinders ist 8|

    Es wiegt schwer, wenn andere reingucken, aber die Befehle nicht das tun, was man gewohnt ist.

  • An den Methoden gefällt mir, dass ich sie überladen kann um zum Beispiel zusätzliche Prüfungen einzubauen. C# schmeisst mir nämlich immer irgendwelche lässtigen Exceptions, wenn ich über das Stringende hinaus arbeite. In vielen Fällen ist mir das aber wurscht und dann sollen die Stringfunktionen einfach mit dem arbeiten was da ist.

    Operatoren lassen sich in einigen Sprachen auch ueberladen ;)

    Aber wenn man eine Funktion baut, die etwas anderes tut als erwartet, dann wuerde ich persoenlich eher einen eigenen Namen waehlen oder eine eigene Klasse bauen, da es eigentlich sehr unschoen ist, Operatoren oder gaengige Funktionen durch eigene Implementierungen zu ersetzen, in denen einem etwas "wurscht" ist :)

    Ja, korrekt. Das mache ich auch so . Es gibt dann einen ExSubstr(). Also nicht überladen sondern erweitern.

    Es wiegt schwer, wenn andere reingucken, aber die Befehle nicht das tun, was man gewohnt ist.

    Richtig!

  • Wobei FOR...NEXT immer mehr durch Collection-Operationen mit Lambda-Ausdrücken ersetzt werden (zum Beispiel map in Javascript). Das klassische FOR() oder FOREACH() braucht man immer weniger. Die String-Operationen gibt es in dieser Form natürlich nicht mehr, da man mit String-Klassen arbeitet. Statt dem ganzen right, left, mid-Gedönse hat man in der Regel eine substring-Methode.

    Hmmm. Keine Ahnung wovon Du da redest. Ich benutze noch VB6.0. Das ist für mich immer noch gut genug. Und man kann ja nicht Software alle paar Jahr komplett umstricken.

  • Wenn ich irgendwo innerhalb einer Aufgabe die Summe aller Elemente brauche, dann denke ich FOREACH. Und weil man mit einer Foreach-Variablen nicht alles machen kann, wird wieder FOR NEXT draus.

    Ich denke nicht an einen Foreach-Ersatz mit Lambda, und ich denke nicht an eine Klasse, die die Summe ihrer Elemente zur Verfügung stellt.

    Beim Lambda sehe ich beim konkreten Anlass keinen Vorteil, und sofort eine Klasse machen ist erstmal auch mehr Aufwand als ein Einzeiler zum Bilden der Summe.

    Verstehe nicht, wofür du bei Lambda und Collections eine extra Klasse brauchst. Der Lambda-Ausdruck ist ja gerade der Einzeiler im Vergleich zu einer herkömmlichen Foreach-Schleife.

    Und es gibt ja nicht nur foreach. Du hast ja in den modernen Sprachen inzwischen einen ganzen Zoo von Collection-Operationen, wie zum Beispiel in Java Filter oder den schon erwähnten map-Befehl. Das ergibt dann schon sehr kompakten und eleganten Code, wenn man das so aneinanderreihen kann.

    Lambdas und anonyme Funktionen sind eigentlich gängige Praxis Wenn man das nicht beherrscht und fließend lesen kann, ist man in modernen Softwareteams schon ziemlich aufgeschmissen.

    Bitte melde dich an, um diesen Link zu sehen.

    5 Mal editiert, zuletzt von detlef (7. Juni 2022 um 17:40)

  • Verstehe nicht, wofür du bei Lambda und Collections eine extra Klasse brauchst.

    Sind wir denn jetzt noch bei BASIC? :gruebel

    Es ging um FOR-Schleifen. Da sind wir noch ziemlich nahe dran. ;)

  • Verstehe nicht, wofür du bei Lambda und Collections eine extra Klasse brauchst. Der Lambda-Ausdruck ist ja gerade der Einzeiler im Vergleich zu einer herkömmlichen Foreach-Schleife.

    Und es gibt ja nicht nur foreach. Du hast ja in den modernen Sprachen inzwischen einen ganzen Zoo von Collection-Operationen, wie zum Beispiel in Java Filter oder den schon erwähnten map-Befehl. Das ergibt dann schon sehr kompakten und eleganten Code, wenn man das so aneinanderreihen kann.

    Lambdas und anonyme Funktionen sind eigentlich gängige Praxis Wenn man das nicht beherrscht und fließend lesen kann, ist man in modernen Softwareteams schon ziemlich aufgeschmissen.

    FOREACH (var item in myCol) Summe += item.Wert
    vs

    myCol.ForEach (delegate(var item) {Summe += item.Wert}

    vs

    for (int i = 0; i < myCol.Count; i++) Summe += myCol[i].Wert

    vs

    Summe = myClass.sum;

    FOREACH passt am Besten zu meiner Denkweise, es erspart mir die für mich immer noch ungewohnten Parameter der C#-FOR-Syntax.

    Hat das LAMBDA irgendeinen Vorteil gegenüber der Foreach-Schleife? Oder ist es nicht eher hintenrum ins Auge, Syntax-Zucker mit Extra-Overhead? Im Bitte melde dich an, um diesen Link zu sehen.findet sich eine for-next-Schleife. Das FOR ist nicht verzichtbar geworden, es ist nur versteckt.

    Die FOR-Schleife kann völlig normal auch Elemente aus der Liste entfernen, was mit FOREACH nicht geht.


    Nur in der eigenen Klasse sehe ich einen Vorteil, weil sie die Eigenschaft sum auf besseren Wegen als mit simplen Durchlaufen aller Elemente erzeugen kann. Zum Preis, dass Du nur noch die Abstraktion beim Lesen des Quelltextes siehst, dass Deine Kollegen die Funktion benutzen und Dir damit Änderungen erschweren, oder dass Deine Kollegen irgendeinen Quatsch drüberschreiben.

    ----------------------------------------

    Im übrigen ging es mir um "Gewöhnung" bzw. die "Denke", die ja hier auch Thema geworden ist.

    Ich durchlaufe Elemente. Ich durchlaufe sie mal einfach, mal Rekursiv mit Backtracking und anderem Pipapo. FOREACH ist mein gedanklicher Startpunkt, FOR, wenn es nötig ist, oder in eigener Klasse, sobald es mir besser erscheint.

    Mein "Job" ist, aus einer Liste alle Kombinationen von Elementen zurückzugeben, die zusammen 10 ergeben. Meine Werkzeuge dazu sind das uralte, primitive FOR und rekursive Funktionsaufrufe. Vielleicht geht es ja auch mit Lambda... Zeig's mir!

    ----------------------------------------

    Und ein paar Elemente moderner Software, die ich kennenlernen musste, finde ich schlecht.

    Wenn irgendwo eine "Variable" benutzt wird, dann möchte ich die Definition dazu sehen können.

    Ich hätte gerne auf eine Variable mit Namen "value" verzichtet und stattdessen eine Deklaration im property set gehabt, wie sie auch in Funktionen verwendet wird.

    Auf den Syntax-Zucker => hätte ich persönlich auch gerne verzichtet.

    Ich möchte sehen, welche Funktionen aufgerufen werden, und andersrum herausfinden können, von wo sie aufgerufen werden.

    CallByName war mal BÄH! Es war für manche Dinge notwendig, aber es behindert Compilerkontrollen und versteckt Aufrufe.

    Und heute gilt: Je Framework, desto Reflection.

        public class HomeController : Controller {
            public IActionResult Index() => this.View();
    }

    Der Namen dieser Funktion und ein Teil des Klassennamens bilden einen Pfad, in dem sich die Datei Index.html befinden muss. Keine Referenzen, keine Probleme beim Umbenennen, kein Laufzeitfehler, keine Hinweise im Output der Konsole... Einfach nur 404, wenn man was falsch macht.

  • Das delegate ist aber eine etwas veraltete Lambda-Schreibweise. Das wird in dieser Form eigentlich nicht mehr verwendet.

    Und es gibt eben nicht nur ForEach, wie ich schon schrieb. Deine Zeile schreibt man inzwischen so:

    int Summe = myCol.Sum(i => i.Wert);

    Deine Lösung sieht ja vollständig so aus:

    int Summe = 0;

    foreach(var item in myCol) Summe += item.Wert

    Wie ich schon schrieb, gibt es eine ganze Reihe von Collection-Operationen, so dass man foreach eigentlich nur noch selten braucht.

    Und das Schöne: Man findet vergleichbare Operationen auch in anderen Sprachen, nur heissen sie meistens anders. ;)

    Aber dass das inzwischen in vielen Sprachen zu finden ist, ist natürlich alles nur Schnickschack. ^^


    Ich durchlaufe Elemente. Ich durchlaufe sie mal einfach, mal Rekursiv mit Backtracking und anderem Pipapo. FOREACH ist mein gedanklicher Startpunkt, FOR, wenn es nötig ist, oder in eigener Klasse, sobald es mir besser erscheint.

    Für mich sieht das eher ein bisschen so aus, wie die Beschränkung auf ein (inzwischen etwas überholtes) Subset des Sprachumfangs. ;)

    Bitte melde dich an, um diesen Link zu sehen.

    5 Mal editiert, zuletzt von detlef (7. Juni 2022 um 20:54)

  • Einspruch stattgegeben.

    Soweit ich mich erinnern kann, hatte das Locomotive Basic auf dem 464 einen eigenen grafischen Zeichensatz.

    Was meinst Du mit eigenen grafischen Zeichensatz? Den hatte doch jeder 8-Bit Rechner gehabt.

    Bitte melde dich an, um diesen Link zu sehen.

    Beim CPC ist es halt sehr einfach da Änderungen zu machen, ohne das man den kompletten Satz

    an Zeichen ins RAM kopieren muss (so wie ich es beim 64er verstanden habe).

    Bitte melde dich an, um diesen Anhang zu sehen. :verehr: .: Mit Bitte melde dich an, um dieses Bild zu sehen.wäre das nicht passiert! :. :prof:  Bitte melde dich an, um diesen Anhang zu sehen.

    :syshack: .: Meine 3D-Drucker Teile auf :. Bitte melde dich an, um diesen Link zu sehen. :strom:

  • int Summe = myCol.Sum(i => i.Wert); // das ist ein Lambda-Ausdruck

    List<T> hat keine Sum-Methode.

    Vielleicht geht dieses hier ja als Ausdruck durch, ich habe es nicht getestet:

    myCol.ForEach (item => Summe += item.Wert)

    Besser als Foreach ist es dann allerdings auch nicht.

    Natürlich kannst Du Linq oder eine andere Extension hinzufügen, da ist ja ein Sum drin.

    Aber das löst ja nicht das ursprüngliche Problem: IRGENDWER muss die Aggregatfunktion zunächst schreiben.

    Meine Behauptung: Das FOR-NEXT ist nicht unnötig geworden, es ist nur verschoben worden.

    Und siehe in Bitte melde dich an, um diesen Link zu sehen.!

    Für mich sieht das eher ein bisschen so aus, wie die Beschränkung auf ein (inzwischen etwas überholtes) Subset des Sprachumfangs. ;)

    Lol, auf zum Pimmelfechten!

    Sum() ist ja eher was für Lib-Herunterlader, eine reellere Aufgabe hatte ich ja oben schon gestellt:

    Mein "Job" ist, aus einer Liste alle Kombinationen von Elementen zurückzugeben, die zusammen 10 ergeben. Meine Werkzeuge dazu sind das uralte, primitive FOR und rekursive Funktionsaufrufe. Vielleicht geht es ja auch mit Lambda... Zeig's mir!

    Programmiere es mit Lambda. Benutze keine FOR-Schleifen und Funktionsaufrufe, die sind Deiner nicht würdig, Du machst sowas schließlich "modern".

    Lade Dir keine Lib herunter, klaue keinen Quelltext bei Stackoverflow.

  • Hier für Java:

    Bitte melde dich an, um diesen Link zu sehen.

    Code
    List<Integer> integers = Arrays.asList(1, 2, 3, 4, 5);
    Integer sum = integers.stream().reduce(0, Integer::sum);
  • Hier für Java:

    Bitte melde dich an, um diesen Link zu sehen.

    Code
    List<Integer> integers = Arrays.asList(1, 2, 3, 4, 5);
    Integer sum = integers.stream().reduce(0, Integer::sum);

    Willst Du mich jetzt verarschen oder was?