BASIC und Python - Was ist denn einfacher zu lernen?

  • Unseen schrieb:

    Schau dir mal Inform 7 und dessen Standardlibrary an.
    Danke für den Hinweis, Unseen, allerdings kenne ich das schon und setze es ganz bewußt nicht ein. Daß es Inform7 nicht für den C64 gibt, spricht leider Bände.

    detlef schrieb:

    wenn es das nicht schon zigfach gäbe
    Nö. Einen schnellen taktzyklengenauen Apple//e-Emulator (mit diversen weiteren Features) gibt es für Windows außerhalb meiner vier Wände tatsächlich nicht.

    detlef schrieb:

    Aber eine Tür ist eine Tür.
    Wie war das mit dem Hammer und dem Nagel? Die Welt ist viel zu komplex, als daß man sie stets auf derartige simple Operationen und Zustände zurückführen kann, zumal die Taxonomie alles andere als klar ist. Ist ein Obstgarten ein Garten? Ist ein Bleistift ein Stift? Im Deutschen ja. Im Englischen nein. Aber das führt jetzt zu weit in die Sprachphilosophie. Bleib ruhig bei Deinen trivialen Problemen.

    ZeHa schrieb:

    Bei einem Adventure wuerde ich solche Eigenschaften eh eher dynamisch machen.
    Ich verstehe Deinen Ansatz, doch wäre meiner Meinung nach der daraus resultierende Code sehr aufgebläht und schlecht wartbar. Es reicht nicht aus, bei einem Objekt Eigenschaften zu definieren, sondern jede dieser Eigenschaften entspricht einem kurzen Programm, in dem z. B. weitere Bedingungen abgefragt werden und weitere Variablen verändert werden. Dazu können durchaus verschachtelte IF-ELSE-Konstrukte nötig sein. Man könnte versuchen, diese Kurzprogramme irgendwie als Aktionstabelle abzulegen, doch meiner Erfahrung nach ist es schlicht einfacher, dafür jeweils ein kurzes Programm zu schreiben.
  • M. J. schrieb:

    Wie war das mit dem Hammer und dem Nagel? Die Welt ist viel zu komplex, als daß man sie stets auf derartige simple Operationen und Zustände zurückführen kann, zumal die Taxonomie alles andere als klar ist. Ist ein Obstgarten ein Garten? Ist ein Bleistift ein Stift? Im Deutschen ja. Im Englischen nein. Aber das führt jetzt zu weit in die Sprachphilosophie. Bleib ruhig bei Deinen trivialen Problemen.
    Genau. Ich baue weiterhin trivale kaufmännische und technische Anwendungen.
    Und überlasse die sprachphilosophischen Probleme den Sprachphilosophen. :D ;( :drunk:
    PET 2001 / CBM 3032 / CBM 3040+4040 / CBM 8250 (Dauerleihgabe) / diverses C64-/VC20-Zeugs (nicht im Einsatz weil eigentlich nicht mein Spezialgebiet :whistling: )

  • @M. J. stimmt, bei einem "richtigen" Adventure waere das nicht ideal, so wie ich es beschrieben habe. Das passt eher bei wiederkehrenden Objekten, so war das eigentlich auch gemeint, habe in dem Moment irgendwie nicht so recht drueber nachgedacht, dass es bei einem Adventure ja doch eher individuelle Objekte sind.
    SHOTGUN - 4-Player Death Match - Website / CSDb / X-Mas
    FROGS - 4-Player Frog Pond - Website / CSDb
  • detlef schrieb:

    Eine gewagte These für jemanden, der wie du selbst zugibt, OOP vermutlich gar nicht verstanden.
    These+Antithese=Diskussion :D
    Freue mich über euren zahlreichen und interessanten Input! :thnks:
    Das hat mir doch das eine oder andere Sichtfenster geöffnet, WARUM es sinnvoll ist, auch kleine Vorhaben mit OO Ansatz zu gestalten.
    Bisher wurde ich immer ungläubig angeschaut, wenn ich zu fragen wagte, weshalb ich OOP machen soll.
    Meistens kam der Standardsatz: "Weil's viel einfacher ist", mit dem ich nicht viel anfangen konnte.
    Natürlich kommt man auf Dauer bei OOP nicht vorbei, wenn man ernsthaft programmieren will.
    Nach und nach habe ich diverse Vorzüge dann selbst bemerkt und war bis vor kurzem auf dem Standpunkt, daß meine "Individual-Lösungen" OOP nicht würdig seien.
    Ein Standpunkt, der wohl revidiert werden muß. ^^
  • Dass OOP bzw. die "alles ist ein Objekt" Philosophie (habe nichts gegen das, programmiere ja selbst auch) nicht in jedem Fall gut ist, zeigen die vielen beknackten OR Mapper der verschiedenen Datenbank-Herstellern, weil OOP Coder Nichts mit Mengenlehre am Hut haben, sprich, sich oft mit SQL schwer tun, und deswegen lieber durch Rows loopen... :bgdev

    Solche Programmier-Erzeugnisse sieht man dann leider auch in "topmoderne ERP Lösungen", die im Backend dann viel langsamer als nötig laufen und dann das DB-Backend-System angeblich als "zu langsam" identifiziert wird. Habe dann die SQL Statements mitgeschnitten und tränenglucksend feststellen müssen, dass die bei Suchtasks tatsächlich Row um Row (!) über 100'000e Records holen und dann vergleichen, ob das mit dem gesuchten Wert übereinstimmt :wand
    Vermutlich weil jemand dachte, dass "eine Fibu-Buchung ein Objekt sein muss", was zwar in der Businesslogik durchaus stimmen mag, aber in der Datenbank-Struktur durchaus andere Paradigmen herrschen und die sollte man nicht einfach ignorieren, nur weil "OOP das Mass aller Dinge ist" oder Mengenlehre nicht so sehr in das eigene Weltbild eines typischen Coders passt.

    Will sagen: Man muss nicht alles versuchen in "OOP Objekte wie die Realität" um jeden Preis reinzuwürgen.
    ___________________________________________________________
    Meine Kreationen: Deviant Art | Toonsup | Flickr | Youtube
    | Twitter
    Avatar: Copyright 2017 by Saiki
  • Mac Bacon schrieb:

    Was hat es mit objektorientierter Programmierung zu tun, wenn $dämlicherProgrammierer SQL nicht kapiert hat?
    Weil die Performance der Datenbankoperationen wegen den Einkapselung in Objekten und wie man dann typische CRUD Sachen (schlecht) umsetzt oft darunter leidet. Wenn man sich nicht damit auseinandersetzen will, wie ein relationales DB Modell arbeitet und nur auf OOP beharrt, dann kommt das nicht gut raus.

    Ich hatte mal ein Kundenprojekt wo wir mit einem zweiten Lieferanten eine SystemIntegration auf DB Basis umsetzen mussten und der andere Lieferant hat das DB System und den Speicher des Applikationsservers regelmässig in die Knie gezwungen weil er seine Klassen Objekte sinnlos mit SELECT Statements (sprich. Millionen von Datensätzen) gefüllt hat.
    Da hat OOP in seinem Tool nichts an der Problematik gelöst sondern mehr Probleme verursacht.

    Ich sage nicht, dass OOP schlecht ist, aber je nach Einsatzgebiet ist es auch nicht immer die einzige bzw. beste Lösung.
    ___________________________________________________________
    Meine Kreationen: Deviant Art | Toonsup | Flickr | Youtube
    | Twitter
    Avatar: Copyright 2017 by Saiki

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von syshack ()

  • syshack schrieb:

    Will sagen: Man muss nicht alles versuchen in "OOP Objekte wie die Realität" um jeden Preis reinzuwürgen.
    Danke für den Hinweis!
    Auch wenn ich das nicht extra erwähnt hatte, aber das habe ich nicht vor :D

    Möge mir die Erkenntnis nicht verwehrt bleiben, wann ich in der Praxis OOP und wann ich Non-OOP einsetze.
    Denn die "xxx-um-jeden-Preis"-Philosophie ist nie optimal, wie einem das Leben immer wieder mal zeigt ;)
  • syshack schrieb:

    Mac Bacon schrieb:

    Was hat es mit objektorientierter Programmierung zu tun, wenn $dämlicherProgrammierer SQL nicht kapiert hat?
    Weil die Performance der Datenbankoperationen wegen [...] und wie man dann typische CRUD Sachen (schlecht) umsetzt oft darunter leidet. Wenn man sich nicht damit auseinandersetzen will, wie ein relationales DB Modell arbeitet und nur auf [...] beharrt, dann kommt das nicht gut raus.
    Ich hatte mal ein Kundenprojekt wo wir mit einem zweiten Lieferanten eine SystemIntegration auf DB Basis umsetzen mussten und der andere Lieferant hat das DB System und den Speicher des Applikationsservers regelmässig in die Knie gezwungen weil er seine [...] sinnlos mit SELECT Statements (sprich. Millionen von Datensätzen) gefüllt hat.
    Da hat [...] in seinem Tool nichts an der Problematik gelöst sondern mehr Probleme verursacht.

    Ich sage nicht, dass [...] schlecht ist, aber je nach Einsatzgebiet ist es auch nicht immer die einzige bzw. beste Lösung.
    Wir reden aneinander vorbei. Was Du da schreibst ist richtig und nachvollziehbar, nur hat es halt rein gar nichts mit objektorientierter Programmierung zu tun. Man kann die von mir durch eckige Klammern ersetzten Textteile auch durch "Maschinensprache", "LISP", "Haskell" oder sonstwas ersetzen, es ändert nichts an der Gültigkeit Deines Beispiels. Also ist Dein Beispiel in diesem Thread völlig irrelevant (nicht dass das jetzt noch was ausmachen würde :P ), und nur darauf wollte ich hinaus.
    Yes, I'm the guy responsible for the ACME cross assembler
  • Das wurde schon in der Vax begonnen. Das war eine C Maschine. Andere CPUs haben Hardware für schnellere Funktionsaufrufe (z.B. rotierende Registerfenster bei Sun Sparc).
    Menschen sind halt nicht fürs Denken in Nullen und Einsen gebaut.
    Hier könnte ihre Signatur stehen!
  • Zum Thema Python:
    Packt Publishing hat heute fuer 24h ein Gratis Python eBook: "Modern Python Cookbook" in den Formaten PDF, ePub, Mobi.

    Ich habe dort einige Buecher schon gekauft und habe deshalb einen Account, aber man muss wahrscheinlich einen Account eroeffnen, um es runterzuladen.
    Es hat uebrigens die ganze Woche jeweils ein anderes Buch (nicht unbedingt Python) gratis pro Tag.

    packtpub.com/packt/offers/free-learning
    ___________________________________________________________
    Meine Kreationen: Deviant Art | Toonsup | Flickr | Youtube
    | Twitter
    Avatar: Copyright 2017 by Saiki