News The Farmer Was Replaced: Automatisierungsspiel mit Coding-Gameplay gefällt

[SheepShaver]

Sieht sehr cool aus. Hab aber schon im Berufsleben genug mit Programmieren zu tun. Zu Hause dann doch lieber nicht.

 

[Cool Master]

Aus reinem Interesse, was ist an der Python Syntax furchtbar?

Kann ich nachvollziehen weil:

• Klammern ({}) fehlen --> Auf Einrückungen angewiesen. (Tab oder Leer, nicht gemischt)
• Dynamisch typisierte Sprache --> Fehler fallen erst beim Ausführen auf.
• Kein keine Switch oder Case --> Viele if else.

Das waren nun mal 3 die mir sofort einfallen, gibt sicherlich noch weitere Punkte die @aLanaMiau ergänzen kann.

 

[mibbio]

Klammern ({}) fehlen --> Auf Einrückungen angewiesen. (Tab oder Leer, nicht gemischt)

Codeblöcke rein durch Einrückungen definieren finde ich auch anstrengend. Einmal ne Zeile zu viel oder zu wenig eingerückt und schon liegt die im falschen Scope. Macht besonders Spaß bei der Fehlersuche, wenn der "Bug" an einer falschen Einrückung liegt. Bei Klammern meckert dagegen spätestens der Compiler, wenn das Aschließen des Codeblocks fehlt.

Kein keine Switch oder Case --> Viele if else.

Python hat seit Version 3.10, also seit ziemlich genau 4 Jahren, das "match ... case" Statement, was sogar noch über ein reines Switch-Statement hinausgeht, weil es Pattern Matching bietet. https://docs.python.org/3/whatsnew/3.10.html#pep-634-structural-pattern-matching

 

[Cool Master]

Cool, war mir nicht bewusst, dass es das in Python nun auch gibt Man lernt nie aus

 

[<jhk>]

Klammern ({}) fehlen

Ist halt keine free-form Sprache wie z.B. C - so hat man zumindest keine Diskussion wo genau die Klammern vom Style her gesetzt werden sollen

Dynamisch typisierte Sprache

Ja, aber man kann ja type hints + pyright/mypy verwenden. Ist nicht ganz das Wahre, aber es hilft.

 

[aLanaMiau]

@<jhk>

Kann ich nachvollziehen weil:

• Klammern ({}) fehlen --> Auf Einrückungen angewiesen. (Tab oder Leer, nicht gemischt)
• Dynamisch typisierte Sprache --> Fehler fallen erst beim Ausführen auf.
• Kein keine Switch oder Case --> Viele if else.

Das waren nun mal 3 die mir sofort einfallen, gibt sicherlich noch weitere Punkte die @aLanaMiau ergänzen kann.

Jup, das trifft es ganz gut. Spätestens bei Copy/Paste wird das Zwangseinrücken zur Folter.

Siehe C, C#, C++, Java, ...: Die mag ich einfach lieber, obwohl die stilistische Struktur nicht durch die Sprache erzwungen wird, find ich die deutlich angenehmer zu lesen.

Gibt aber auch eine tolle Lösung für das Problem: https://pypi.org/project/Bython/

 

[luckysh0t]

Tolles Spiel, aber den furchtbaren Python-Syntax würde ich mir freiwillig nie antun wollen.

Immerhin ist es kein Perl ^^. Arbeitsbedingt wäre Ruby praktisch xD.

 

[XamBonX]

Sehr geil um Jungendliche und Kinder an Programmieren zu erfreuen.

 

[Bright0001]

[1] Zugegeben ist das Beharren auf saubere Programmierung auch oftmals nicht teil einer formalen Ausbildung -.-

Vergebliche Liebesmüh, damit verhält es sich imo wie mit Datenbackups: Kann man rauf und runter predigen, und alle nicken und finden es sinnvoll - aber richtig begreifen tun es die meisten erst dann, wenn sie das erste Mal auf die Schnauze gefallen sind.

Ich finde Coden eigentlich richtig cool, aber mir fehlt die Motivation, mich wirklich intensiv damit zu beschäftigen. Ich habe mal Python ausprobiert, aber das war für mich einfach ziemlich langweilig ^^

Aber wenn es dich langweilt, dann findest du es nicht cool, oder verstehe ich da was falsch?

Ne Programmiersprache ist wie eine Holzwerkstatt; Man hat erst dann richtig Spaß damit, wenn man das, woran man arbeitet, selbst cool findet.

aber wäre doch viel doller, wenn man das, was man da übt, direkt danach auch 1:1 in seiner Python-IDE anwenden kann

Aber das geht, der Wert des geschriebenen Codes steckt am Ende ja in der Logik und nicht in den getippten Buchstaben.

Ich glaub dem Entwickler gings eher darum Schabernack zu unterbinden, sprich wenn da Leute mit Python-Skills um die Ecke kommen und anfangen das Spiel von innen heraus zu zerlegen.

Ich versuch das in der Freizeit so gut wie möglich zu unterdrücken und es verkehrt sich dann komplett ins Gegenteil wodurch ich dann im Grunde antioptimierung betreibe.

Fühl ich; Wenn man sich erst einmal eingestanden hat, dass man da einfach Spaß dran hat, dann wird sowohl Optimierung als auch Anti-Optmierung schlicht zum Zeitvertreib, und man braucht sich am Ende nicht ärgern, wenn der Aufwand das Ergebnis aus "objektiver" Sicht nicht wert war.

 

[Piktogramm]

@Bright0001
Also sich da schon nach dem ersten "Missgeschick" auf den Hosenboden zu ist meine Augen schon sehr vorbildlich.

 

[calluna]

Dynamisch typisierte Sprache --> Fehler fallen erst beim Ausführen auf.

Python gibt es seit Jahren auch mit einem (ausdrucksstarkem) Typsystem.

Die typischen IDEs verwenden dieses Typsystem unabhängig vom Typchecker, um auch ohne den auf viele Fehler hinzuweisen.

 

[samuelclemens]

Ich finde Coden eigentlich richtig cool, aber mir fehlt die Motivation, mich wirklich intensiv damit zu beschäftigen. Ich habe mal Python ausprobiert, aber das war für mich einfach ziemlich langweilig ^^

Versuch eher Zielorientiert an die Sache ran zu gehen. Nicht "Ich will jetzt Python lernen" und dann mit Tutorials die Basics reinziehen indem man simple "Hello Word" oder Taschenrechner umsetzt. Das ist langweilig!!!
Such dir was aus wo du mal gedacht hast das würde ich gern mal umsetzen oder ändern aber dafür hätte man coden müssen.
Bei mir zb mit Java und Minecraft Mods die ich gern angepasst hätte. Kurz: Ich hab nie richtig Java gelernt. Ich hab mir lediglich die Sachen beigebracht die ich für mein Ziel benötigte.
Ich weiss, da schreien viele echte Coder nun auf. Man muss es doch von der Pieke auf lernen. Dieses Gefrickel ist doch nix! Und Recht haben sie! Sofern man vorgehabt hat Java zu lernen.

Man kann sich also erst mal ein Zielprojekt setzen das man konkret umsetzen will. Und danach schauen mit welcher Platform oder Gameengine man am besten umgehen kann, nicht die am effektivsten geeignete.
Ich mag zb sehr gern Godot oder GDevelop. Bei letzterem kommt man nur am rande mit Coding in berührung. Aber es hilft enorm wenn man vorher schon öfters mit Code "gefrickelt" hat!
Irgendwann, wenn es sehr gut läuft reicht einem das vielleicht nicht mehr und sucht sich was herausfornderes wie Unitiy mit C#!

KI hilft einem enorm weiter weil es einen mit Engelsgeduld an die Hand nimmt und macht das autodidaktische lernen sehr viel einfacher und zielorientierter. Keine Scheu sich auch Code komplett generieren zu lassen von der KI. Es wird oft nicht auf anhieb so hinhauen wie man will. Aber durch das ständige "ausbessern" mithilfe der KI lernt man versehentlich nebenher auch ein wenig coden. ChatGPT zb erkennt schnell das man ein Laie ist und erklärt einem oft selbstständig die einzelnen Schritte ohne extra zu fragen. Und es rollt nicht genervt mit den Augen weil man von nix ne ahnung hat.🙄

 

[blackiwid]

Programmieren ist immer gleich.
Eingabe, Verarbeitung, Ausgabe.
Schleifen, Variablen, ...

Dem würde ich widersprechen, gut wenn du natürlich viel in das ... rein steckst und alles was du auf schreibst optional an siehst dann mag es stimmen, aber gut in python gibts das auch "map" aber in Python hatte der Hauptentwickler ein hass auf funktionale Programmierung und da er mit PEPs und syntax Sugger darauf einfluss nimmt was man benutzten soll ist es wenig encouraged das zu benutzen.

Dann gibt es keinen Blockscope, was mich auch tierisch nervt. Aber mit map lassen sich ähnliche Aufgaben lösen wie mit ner Schleife aber es ist keine Schleifen function in dem Sinn. Beispiel (sorry benutze lisp weil mir das näher liegt)

(let* ((nums '(1 2 3)))
  (mapcar '1+ nums))

Mit schleifen in Python ist das folgendes:

nums = [1, 2, 3]
nums_incremented = []
for num in nums:
    nums_incremented.append(num + 1)
print (nums_incremented)

Das bisschen ein best case Scenario weil es + als funktion in lisp gibt (aber gibt dort deutlich mehr) und weil ich den output ausgebe und in lisp der Letzte Wert aus gegeben wird, (EmacsLisp).

Aber auch wenn ichs die function ausschreibe z.B. für increment um 2 (+2) wo es keine extra function in elisp gibt und das in ne neue variable auffange (auch wenn das meist unnötig ist da man in Lisp viel verschachtelt statt zwischenvariablen zu verwenden) wirds nicht so viel schlimmer:

(let* ((nums '(1 2 3)))
  (let* ((nums-incremented
      (mapcar (apply-partially '+ 2) nums)))))

apply-partially ist hier ein spezifisches Lambda wo man eine function mit z.B. 2 parametern 1 fest setzt und die man eine function mit 1 parameter zurück kriegt die sich wieder für mapping eignet.
Wenn es komplexere Sachen sind die man normales lambda benutzen aber bei so was einfachem macht es den Code nur länger:

(let* ((nums '(1 2 3)))
      (mapcar (lambda (num)
            "my increment function"
            (+ 1 num))
          nums))

Also man hat hier "anonyme Funktionen" (also welche ohne Namen) es gäb dann zur Vollständigkeit auch noch recursiven Code wo sich eine function immer wieder selbst auf ruft bis ein z.B. Counter einen Wert erreicht hat und da incrementiert eine weitere Alternative zu "normalen" loops aber benutz ich nie...

Mein Punkt ist ich benutze fast nie loops, dafür aber map, ein Vorteil ist, die reihenfolge der Ausführung ist egal, und daher kann man sich vorstellen das vereinfacht ein 8 Kern Prozessor 8 Anweisungen gleichzeitig aus führt, statt auf die ergebnisse des vorigen Loop durchganges zu warten. Daher ist es eher ein Führe auf alle elemente der Liste Operation X aus und dann eben nicht als Loop sondern egal in welcher Reichenfolge oder alle "gleichzeitig". Was es oft dann auch schneller macht, potenziell auch sicherer, Sprungvorhersage die man bei Schleifen (korrigiert mich) zum schnelleren Ausführen benutzt hat ja die ganzen Sicherheitsprobleme der letzten Jahre verursacht...

 

[calluna]

@blackiwid

Welche Zielgruppe hat dein Beitrag? 😉

In Lisp / Scheme / Racket / Clojure / Haskell / Scala wirst du Map verwenden (im heutigen Java und C# übrigens ebenso) - aber in C wird es eine Schleife sein.

In Python sind es meist List-Comprehensions ähnlich denen aus Haskell, deswegen ist da Map überflüssig… oder Schleifen, wenn es der Verständlichkeit dient.

Und Einfachheit und Verständlichkeit ist das wichtigste, wenn es darum geht, dass den Quellcode möglichst viele im Team verstehen, die alle unterschiedliche geistige Fähigkeiten haben: eine Stärke von Golang. (Und auch idiomatischem Python).

PS: Für Kinder und Jugendliche ist der Einstieg über prozedurale Programmierung am einfachsten - auch wenn es Einführungskurse an Universitäten mit vereinfachten Versionen von Scheme / Racket gibt, aber da kann immer schon ein bestimmtes Vorwissen erwartet werden.

 

[blackiwid]

Welche Zielgruppe hat dein Beitrag?

Für @Arboster weil ich auf den geantwortet habe und jeden anderen der sich dafür interessiert wie du z.B.

Ich halte den Python Urban Myth das Leserlichkeit von Code das wichtigste ist, das ist wie wenn man sagt das Webmail pauschal besser wie Mailprogramme sind weil der Einstieg einfacher ist.

Auch würde 2 Mittelschwer verständliche Zeilen code nicht perse schwerer einstufen als 5 leicht verständlichere Zeilen, wenn wir pro einfacher Zeile 1 Verständnisaufwand Punkt definieren und für mittelschwere 2 dann sind wir bei dem Lisp Beispiel bei 4 Punkten bei dem Python bei 5 Punkten.

Dazu kommt das ich bei nem Mini Beispiel es nicht nen riesen Unterschied macht weil ich alles im Auge habe in beiden Versionen, wenn ich aber ne Bildschirmseite Lisp habe ein paar Funktionen und ich brauche bei Python 2 Seiten oder gar mehrere Dateien muss man Dateien wechseln oder Seiten scrollen und hat nicht mehr alles auf einer Seite. Oder bei noch größerem Code hat man halt doppelt so viel Dateien oder doppelt so große Funktionen.

Dann sieht man den Wald vor lauter Bäumen irgendwann nimmer.

Meine Optimierung ist welche Sprache kann ich besser refaktorieren, denn wenn ein Projekt mal bisschen größer wird dann hat man mit Python wahrscheinlicher extrem viel schlechten Code den man Refaktorieren müsste, man hat dann das Problem später aber ein viel viel größeres der Code komplett unmanagable machen kann.

Für nen Rapid Prototype mag so ne Sprache wie Python besser sein, aber für Hochwertige Software die dann auch dauerhaft gepflegt werden muss halte ich davon nichts weil die Sprache auch ohne klassisches Repeating sich trotzdem wiederholt.

Auch wenn nach DRY hier mein Python Beispiel kein DRY ist, wiederholt es Variablennamen etwas was ich in ne ähnliche Kategorie packe. Also 3x steht da "num_incremented" und 2x "nums" und 2x "num" während in Lisp ich nur 2x nums habe sonst gar nichts.

Ich denke ich habe das Beispiel (Increment) so einfach gehalten das es auch trotz eines Map operators nicht schwerer ist wie eine Schleife also Anfänger Level, sicher die 2 unteren Beispiele werden dann ein wenig komplex aber habe versucht Kritik zu antizipieren oder fair zu sein. Mag sein das ich da bisschen zu ausführlich wurde.

Letztlich muss der Leser das nicht alles verstehen als Anfänger, nur das es eine Alternative zu Loops gibt und alternativen zu procedular Programming gibt.

Btw haben auch Sekretärinen mit Emacs die keine Programmierer waren über Macros ganz schnell Emacs_lisp gelernt, also ist es nicht so alien das Einsteiger das nicht lernen könnten ich halte es eigentlich sogar einfacher aber vielleicht bin ich da leicht Autistisch.

RMS said that "programming new editing commands was so convenient that even the secretaries in [Bernie Greenberg]'s office started learning how to use it.
They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off.
They read the manual, discovered they could do useful things and they learned to program.

Immerhin muss man sich weniger mit dem rechten Gehirn ständig millionen perfekter oder alternativ hässlicher / schlechter Funktions- und Variablennamen aus denken und kann dann im Docstring stattdessen genauer ausdrücken was man will statt es verzweifelt auf 1 guten Namen runter zu brechen.

Ich mein die Vorstellung das eine Sprache die stark mit Pseudocode ähnlich ist fast 1:1, genauso gut für echten Code sein soll, ist verrückt.

Wir können mal noch das thema 1 Liner ansprechen, es hat ne eigene Syntax also musst du die Syntax einer 2. Sprache lernen um halbwegs schönen Python Code zu bekommen.

Leute mit einem "Complitionist Brain" also Leute die Spiele zu 100% durch haben wollen alle Archivements in Games haben wollen, die werden mit ner Sprache wie Python auf dauer wahrscheinlich nicht glücklich werden und davon gibts viele Menschen, weil ein "complete" code nicht schlecht optimierter Code ist und dafür brauchts Refactoring und eine Sprache die isch dazu eignet, eine die für 1 Liner ne andere Syntax hat lässt sich schwer Refactorieren und da "Gamification" bei Programmierung ein großes Thema ist finde ich den Completionist aspekt durchaus relevant.

Btw die meisten die das Spiel gut finden können laut der Umfrage hier schon Programmieren also rede ich hier nicht nur mit absoluten Anfängern mit 0 Programmierkenntnissen.

 

[Elderian]

Letztlich muss der Leser das nicht alles verstehen

Das stimmt.
Kannst Du Deinen Beitrag nochmal in zwei Sätzen mit Satzzeichen zusammenfassen?

Ich lese heraus, dass Du Python nicht magst.

Ich hatte als C/C++-Entwickler anfangs nur Python auch meine Schwierigkeiten, aber mittlerweile mag ich es ganz gern...

 

[blackiwid]

Ich hatte als C/C++-Entwickler anfangs nur Python auch meine Schwierigkeiten, aber mittlerweile mag ich es ganz gern

Ich mochte es mal gern, hab in der Schule mit C++ angefangen, dann kam Java dazu das ich ne weile mochte, und im Studium lernte ich dann erst C und auch C++ und auch Java (oder wiederholte es), aber irgendwo auch ein bisschen Nebenbei Python wo ich dann mehr mochte und meine Diplomarbeit machte.
Dabei stoß ich doch an Grenzen, sicher weil ich mir Dinge auch nicht umfassend sondern learning by doing viel und in Teilen Autodidaktisch bei bringe.
Gerade wenn man dann noch OOP im Programm hat und es sehr viel Code werden kann und es sehr viel Coupling gibt, dann merkt man wie schlecht sich Python refactorieren lässt. Sicher es ist nicht unmöglich aber die Lebenszeit ist Endlich und die Komplexität und Umfang kann so groß werden das es in ner Kosten/Nutzenrechnung nicht mehr funktioniert vor allem wenn man nicht dafür bezahlt wird.

Wie dem auch sei habe leider erst nach dem Studium Emacs für mich entdeckt, dachte immer es wäre nen komischer Editor mit komischen Tastenkombinationen aber es ist mehr ein Lisp Interpreter wo eine Art Default Editor Code, wie ne Art Programmierbarer Taschenrechner... den man eben auch mit dem eigenen Lisp Dialekt konfigurieren muss. Und irgendwann wurde halt aus der Notwendigkeit Funktionen und Konfigurationen in Lisp schreiben zu müssen eine Leidenschaft. Eines der ersten Dinge war das ich in ganz wenigen Zeilen Code ein riesen Python Projekt ersetzen konnte in dem ich ein vorhandenen Email Client in Emacs eben bediente, Quasi vergleichbar zu Word Macros. Sicher da vermischt sich die Vorteile des "Editors" und der Sprache, aber ja da hab ich Blut geleckt.

Sorry tu mich schwer mich kürzer zu halten, mein Kommentar hier war gar nicht sooo sehr gedacht um meine Abneigung gegen Python zum Ausdruck zu bringen sondern mehr das es nicht nur Schleifen gibt bzw eben auch funktionale Programmierung. Ein anderes Projekt das für Leute mit C oder Fortran ähnlichen Sprachen / Syntax näher sein dürfte wäre vielleicht Julia, an Python stört mich vieles wie keine Blockweiten Scopes, das es noch schlimmer macht wie die meisten anderen procedural Sprachen.

 

[calluna]

@blackiwid

Ich kann verstehen, was du an Lisp gut findest. Ich habe einmal SICP durchgearbeitet. Und mir gefällt Haskell.

Aber ich weiß, das auch mit Python komplexe und wartbare Software gebaut werden kann - weil es solche Projekte gibt.

Wenn jemand die Sprache nicht mag - für mich kein Problem. Es gibt mindestens 30 interessante Programmiersprachen… von C über Erlang bis Zig.

Im beruflichen bin ich da aber pragmatisch… da wird der Code für andere Menschen geschrieben - und für das eigene zukünftige Ich.

Und wenn 30 hässliche Zeilen für die meisten verständlicher sind als elegante 10 - dann werden es die 30. 😁

 

[blackiwid]

Und wenn 30 hässliche Zeilen für die meisten verständlicher sind als elegante 10 - dann werden es die 30.

Kann ich verstehen, irgendwie muss man Geld verdienen.

Aber ich weiß, das auch mit Python komplexe und wartbare Software gebaut werden kann - weil es solche Projekte gibt.

Man kann auch mit Brainfuck sicher komplexe Programme schreiben, das macht es nicht zu guten Sprachen. Es ist auch nicht NUR die Sprache wie ich gesagt habe, es ist auch das Tooling.
Z.b. liebe ich an Lisp Paredit oder ähnliche Tools das ich Code als logischen Tree bearbeiten kann nicht nur als Text, aber nicht nur das, selbst Doku zu anderen Sprachen oder debugger/interpreter integration von anderen Sprachen ist in Emacs nicht immer so doll, das gibts teils natürlich in anderen IDEs mag aber Emacs lieber, das ist mir fast noch wichtiger als Lisp.

Aber sowas wie paredit gibts für andere Sprachen nicht wirklich, es ist bisschen am werden aber nicht da wo ichs will.

Das heißt ich müsste 50-90% meiner Produktivität auf geben neben hässlichem Code schreiben um eine andere Sprache zu schreiben.

Python kann ok sein wenn man am Anfang des großen Projekts die Sprache mehr oder weniger perfekt beherrscht also mit Generatoren "yield" und all dem Zeug und auch klar ist wann man was wie am effizientesten einsetzt oder ne hohe Tolleranz für schlechten Code hat inclusive Tools die 1000x wiederholungen von Variablennamen auf einmal überall verändern.

Aber wenn man die Sprache nur Oberflächlich beherscht und auch OOP nur so lala beherrscht führt es ins Disaster, und alles was du über OOP in Schulen und meisten selbst Unis / FHs lernst ist sehr schlecht.

Deshalb gibt es auch sehr sehr viel frustrierte Java Menschen die mit OOP stark hadern, vereinfacht gesagt sollte man in OOP vermeiden so weit es geht Attribute in Klassen zu definieren und Zustände so weit wie möglich vermeiden und stattdessen quasi nur Methoden in Klassen rein schreiben also Fokus, stattdessen lernt man Klassen immer als die Dinger mit vielen Eigenschaften dem widerspricht der erfinder von OOP selbst, er fühlt sich missverstanden, kann natürlich auch taktisch so sagen weil es zu massiven Problemen führte und man so sagen kann "hab ich nicht so gemeint".

https://de.wikipedia.org/wiki/Objektorientierte_Programmierung

Vererbung war eine weitere Fehlleitung benutzt kaum jemand wurde aber immer groß beworben früher... aber ja es geht um "messaging" nicht um fixe Zustände die Programme weniger dynamisch machen. Also das machen schon 90% aller OOP Programmierer falsch, dann kommen noch Pythonprobleme oben drauf...

Natürlich ists irgendwann egal wie schlecht der Code ist wenn die K.I. die arbeit macht und den schrecklichen Code schreibt.

Aber ja Python auch wenn ich es mal mochte ist so ziemlich die letzte Sprache die ich von der Sprache her gerne benutzten würde alleine das es keine Blockweiten Scopes gibt, ist für mich die absolute Katastrophe und geradezu barbarisch.

 

[aid0nex]

Cool! Sowas ähnliches - also Coding spielerisch lernen - hatten wir damals (2013) schon im Informatik Unterricht an der Schule. Greenfoot hieß das Tool, basiert glaube ich auf BlueJ (Java).