Wer programmiert Basic von Euch ?

Es gibt 362 Antworten in diesem Thema, welches 39.504 mal aufgerufen wurde. Der letzte Beitrag (29. September 2023 um 22:13) ist von Goodwell.

  • Ich habe zuerst Radfahren gelernt, darum werde ich nie ein guter Autofahrer. Und wenn ein Rennfahrer in seiner Privatzeit einen Smart fĂ€hrt, kann er im Rennen auch nur schlecht sein.

    Nicht alles was hinkt, ist ein Vergleich. :D

    Menschen, die zuerst Deutsch lernen, werden nie Englisch oder Französisch lernen können, weil die Grammatik ganz anders ist, von Chinesisch ganz zu schweigen.

    Menschen die zweisprachig aufwachsen, lernen spÀter weitere Sprachen viel schneller. Nur mal so als ein Beispiel, wo deine Beispiele daneben liegen. ;)

    Aber diese Art der Vergleicherei ist sowieso unsinning.

    ... weil ja grundsÀtzlich kein Mensch in der Lage ist, mehrschichtig zu denken und dazu- oder umzulernen. Ich frage mich nur, woher die Leute, die so was behaupten, ihre Gewissheit haben.

    Nimmst du wirklich immer alles so tierisch ernst? Der hatte ĂŒberhaupt keine Gewissheit. Der hat einfach mal einen rausgehauen, weil es als MitbegrĂŒnder der Strukturellen Programmierung Basic vermutlich abgrundtief gehasst hat. Das hatte ich doch eben schon geschrieben.

    Wenn ich so einen Spruch lesen, dann schaue ich mir doch an, von wem der kommt und was der fĂŒr einen Hintergrund hat und was er ggf. damit bezwecken wollte.

  • Damit kann man IMO ĂŒberhaupt keine "guten" Programme schreiben

    Definiere "gute Programme". Windows und dessen Anwendungen z.B.? Wo man auch auf einem riesigen Monitor Dialogfenster absichtlich starr und winzigklein macht, damit man sich darin wie mit Scheuklappen 'nen Wolf scrollt (um nur eine von unzÀhligen Idiotien zu nennen)? Ist das die Errungenschaft "guter strukturierter Programmierung"? Und stattdessen war "Die Fugger" also einfach nur Mist, allein weil es in BASIC geschrieben wurde?

    Ich kann z.B. CNC fĂŒr Entspanungsmaschinen, eine lineare Sprache, die genau darauf zugeschnitten und dafĂŒr angemessen ist. Genauso ist es mit allen anderen Systemen. Und bei allen kann damit etwas Gutes oder auch Schlechtes herauskommen. Oft liegt es gar nicht an der Sprache, sondern an Ideen und ihrem Sinn. Die Möglichkeit der Strukturierung allein macht noch kein gutes Programm. Und unter "gut" verstehe ich eben, dass es den BedĂŒrfnissen des Anwenders oder Spielers gerecht wird.

  • Damit kann man IMO ĂŒberhaupt keine "guten" Programme schreiben

    Definiere "gute Programme".

    Das hatte ich in dem von dir rausgekĂŒrzten Teil versucht.

    Bitte melde dich an, um diesen Link zu sehen. - Ratespiel ‱ Bitte melde dich an, um diesen Link zu sehen. - BASIC-Erweiterung ‱ Bitte melde dich an, um diesen Link zu sehen. - Sprite-Editor ‱ Bitte melde dich an, um diesen Link zu sehen. - Zeichensatz-Editor ‱ Bitte melde dich an, um diesen Link zu sehen. - 2048 Blöcke

  • Die ganze Diskussion hebt mir etwas zu sehr ab.

    Es ging doch darum , wer in Basic programmiert?

    Also - Finger heb' - ich hier. hĂŒpf.

    Und das, weil es ein toller Freizeitspaß ist.

  • Und unter "gut" verstehe ich eben, dass es den BedĂŒrfnissen des Anwenders oder Spielers gerecht wird.

    Das wĂŒrde ich schon etwas enger fassen. Ein gutes Programm ist auch wartbar, leicht erweiterbar. Zumindest der Programmierer sollte es nach einem Jahr noch verstehen. :D

  • Damit kann man IMO ĂŒberhaupt keine "guten" Programme schreiben

    Definiere "gute Programme".

    Das hatte ich in dem von dir rausgekĂŒrzten Teil versucht.

    Sorry, war undeutlich, die Aufforderung sollte eher rhetorisch sein und an den Schlaumeier (und seinen Vertretern) gerichtet, von dem das Zitat ist, um das es hier ging. ("gutes Programmieren").

    Aber wer sagt, dass jeder, der etwas entwickelt, mit anderen zusammenarbeitet, die daran mit- oder weiterarbeiten? Wenn ich im C64-Studio jede Menge Anmerkungen und ErklÀrungen habe, reicht mir das doch. Da steht dann an jedem Abschnitt und jeder Unterroutine, was da passiert. Sehe da kein Problem.

    Da muss man dann eben noch die Perspektiven unterscheiden. Als Anwender oder Spieler reicht mir, wenn das Programm fĂŒr mich gut ist. TrueCrypt ist so ein Beispiel, das zwar gut war, aber aus einem schrecklichen Frickel-Code besteht. Umgekehrt kann es zwar gut organisierte Projekte von einem Team geben, aber dann dennoch Murks, oder zumindest in Teilen. Schau Dir mal die KI in "Worms Revolution" vom Team17 an und denke mal darĂŒber nach, was da der komplette (extra programmierte!) Schwachsinn ist, der einfach nur nervt. Können wir uns gern mal im KI-Thread drĂŒber unterhalten. WĂ€re auch fĂŒr den "Zufall"-Thread geeignet.

    Nicht alles was hinkt, ist ein Vergleich

    Ich weiß, ich könnte 138000 Analogien aufzĂ€hlen, und selbstverstĂ€ndlich hinkt alles. Kenne ich. :D

    Menschen die zweisprachig aufwachsen, lernen spÀter weitere Sprachen viel schneller.

    Und wo hat der Schlaumeier gesagt, dass es nur um eine BASIC-Variante ging? Und selbst, wenn Du Pascal oder Fortran dazu hattest, hat das nichts mit OOP und dergleichen zu tun, analog zu EN/FR/NL etc. vs. Chinesisch oder gar Finnisch.

    Der hatte ĂŒberhaupt keine Gewissheit.

    Auf einmal. Vorher hieß es von Dir selbst noch, dass es genauso sei, wie er sagt. Genau wie derjenige, der sich nach langer Zeit hier extra anmeldet, obwohl er ja nicht viel Zeit hat, nur um hier diesen deplatzierten Quark reinzuhauen, anstatt was Sinnvolles zum Thread-Thema beizutragen. Was will man damit bezwecken, außer den BASIC-Liebhabern durch die Blume mitzuteilen, dass sie alle rĂŒckstĂ€ndig und dumm sind und niemals ein gescheiter Programmierer werden können bzw. konnten? WofĂŒr genau brauchen wir das? Du siehst ja an der Diskussion schon, die dadurch wieder entbrannt ist, dass das vielen eben nicht am A... vorbei geht und/oder sie das anders sehen, und alles ist mal wieder off-topic dadurch. Einfach nicht darauf eingehen? Damit Initiator und Zustimmende sich bestĂ€tigt fĂŒhlen können? Man könnte es alternativ auch einfach mal lassen. Leben und leben lassen! Nicht zu verwechseln mit .. Kleben und kleben lassen! ^^

  • Der hatte ĂŒberhaupt keine Gewissheit.

    Auf einmal. Vorher hieß es von Dir selbst noch, dass es genauso sei, wie er sagt.

    Nö. Guckst du hier:

    Bitte melde dich an, um diesen Link zu sehen.

    und hier:

    Bitte melde dich an, um diesen Link zu sehen.

    Ich dachte die genauen Formulierungen wÀren dir so wichtig. Bei mir hast du aber kein Problem, die umzudeuten. ^^

    Du siehst ja an der Diskussion schon, die dadurch wieder entbrannt ist, dass das vielen eben nicht am A... vorbei geht und/oder sie das anders sehen, und alles ist mal wieder off-topic dadurch.

    Irgendwas findet man immer, worĂŒber man sich aufregen kann. :nixwiss:

  • Also es ist mir völlig egal ob basic v2 eine gute Programmiersprache ist oder nicht. Es ist das, was da war - und ist - auf CBM.
    Wer 1982 mit basic startete war bald darauf am Assembler dran , anfangs gemischt ,spÀter 100% pur.

    War doch in C64 basic kein Problem kreuz und quer im Program herumzuspringen, solange man sich erinnern kann was man tut - oder wenigstens eine Mitschrift nebenbei auf Papier hatte.

    Keiner damals kannte c++ oder Java ! Nichts davon existierte. Struktur gab "GOSUB Unterprogramm und Retour"- mehr brauchts nicht.

    Wozu lokale /globale Variablen ? Wozu eine private Klasse ? Wozu Public ? Wenn es im RAM steht kann ich es anspringen und das Resultat auslesen. Und wenn ich am Stack herum manipulieren will - dann hat es auch einen Grund.

    Kurz gesagt: Wer den Überblick behĂ€lt braucht solchen Mist nicht.

    Jetzt grossspurig die Vorteile on OOP nachzuplappern weil man es inzwischen "beruflich" verwendet und inzwischen sein denken darauf abstrahiert / eingeengt hat .... na ja.

    Die wenigsten von Euch heissen James Gosling oder Bitte melde dich an, um diesen Link zu sehen. und auch nicht in seiner Position - Ihr habt das nicht entwickelt oder erarbeitet !


    Klar das die heutigen Hipster (Skript-) Kiddies die mit OOP aufwuchsen , kotzen gehen wenn sie Selbstmodifizierenden ASM Code sehen oder ĂŒberlegen warum jemand den 2nd Level_Cache intercepten um einen Treiber zu debuggen (zb. Denuvo Analyse - klar macht nicht jeder, jeden Tag hauptberuflich)

    Aber fleissig Spiele aus dem Torrent ziehen die mit Cracks laufen und niemand von denen Versteht was eigentlich innen abgeht ...

    So wie ich kotzen muss wenn ich ein UML machen soll.


    Nice to read:

    Bitte melde dich an, um diesen Link zu sehen.

  • EgonOlsen71

    Funktioniert Super (!) - bin begeistert

    Hab aber noch folgende kurze Fragen:

    Angenommen ich erweitere das Textadventure zu einem GrafikAdventure:

    Wie muss ich vorgehen wenn ich in Inheritance einen Maschinencode Teile benötige fĂŒr SIDPlayer und eine Koala Bildschirm Load / Show funktion.

    Also wie ich das ausprogrammieren soll ist mir klar.

    - Aber wie bekomme ich Maschinenprogramme in das Compilat hinein?

    - Source oder BinÀrdatei ?

    Data WĂŒsten ? oder nachgeladen von Disk mittels

    Code
    100 Load"bla.bin",8,1

    und vorallem

    - wo ist das dann im Speicher ? Wo soll es sein ?

    - Hab ich ĂŒberhaupt noch internen Speicher frei wenn die Grafiken bei $e000 - $FFFF liegen und der Videoram bei $c800

    Appropos Data : was macht Mospeed mit all den Data strukturen ? werden die ins RAM kopiert und verwendet oder bleibt das BASIC Token P-Code wie im Original?

    Wo liegen im Compilat eigentlich die Variablen ?

    Kann man Basic Programm Overlays im Mospeed compiler haben / machen ?

    - Also Programme wie "RĂ€ume" welche als Basicprogramme auf der Disk liegen, extra compilieren ->

    - zurĂŒck auf die Disk und

    - verwenden aber im Spiel die Variablen vom Hauptprogramm ?

  • Wie du ein Maschinenprogramm ablegst, ist letztendlich dir ĂŒberlassen. DATAs gehen, sind aber letztlich Platzverschwendung. Nachladen geht auch, das wird dann dahin geladen, wo es abgespeichert worden ist (die Adresse steht in den ersten zwei Bytes einer PRG-Datei). Im Falle von MOSpeed kannst du einfache Routinen auch direkt inline im BASIC-Code hinschreiben (Bitte melde dich an, um diesen Link zu sehen.)...das lĂ€uft dann aber natĂŒrlich nicht mehr im BASIC selber.

    Wenn du den -compactlevel auf 3 setzt, hast du noch ein wenig Platz zwischen Programmende und $C800...aber nicht besonders viel. Das Kompilat ist halt nun mal recht groß. Kann gut sein, dass man das im BASIC-Programm selber noch optimieren kann. Da habe ich jetzt nicht reingeschaut. Dann mĂŒsstest du aber den Parameter -varend noch auf $C800 setzen, sonst ĂŒberschrieben die Strings dein Videoram. Wenn du eh den ganzen Videokram nach oben schiebst, kannst du z.B. auch im ehemaligen Bildschirmspeicher dein Maschinenprogramm ablegen (also ab 1024 oder noch davor ab 820).

    MOSpeed ist kein P-Code-Compiler, von daher entstehen aus DATAs auch keine Tokens. Die Daten liegen "schlau" konvertiert in ihre eigentlichen Typen im Speicher. D.h. Strings liegen da als Strings, Zahlen als Bytes, Words oder Floats. Ggf. muss die Compilerruntime beim Einlesen dann konvertieren, weil man in BASIC V2 Zahlen in DATAs auch als Strings einlesen kann, aber das bekommst du nicht mit.

    Die Variablen liegen hinter dem Programm. Der normale Aufbau ist:

    1. Init
    2. Kompilat
    3. Runtime
    4. Konstanten
    5. Variablen
    6. Stringspeicher

    Wenn du -bigram=true nutzt, dreht sich das ein wenig um und die Runtime liegt dann vor dem Kompilat, aber sonst bleibt es gleich. Wenn du mit -generatesrc=true kompilierst, entstehen diverse zusÀtzliche Dateien. Eine davon ist die Assembler-Quelldatei. Da kannst du sehen, was wo zum Liegen kommt und wie das aussieht.

    Overlays sind nicht vorgesehen.

    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.

  • Der hatte ĂŒberhaupt keine Gewissheit.

    Auf einmal. Vorher hieß es von Dir selbst noch, dass es genauso sei, wie er sagt.

    Nö. Guckst du hier:

    Bitte melde dich an, um diesen Link zu sehen.

    Ja, da sagst Du, dass die Aussage "im Kern" doch richtig sei. Aber offenbar gibt es hier unterschiedliche Auffassungen darueber, was denn nun "der Kern" 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.

  • Der hatte ĂŒberhaupt keine Gewissheit.

    Auf einmal. Vorher hieß es von Dir selbst noch, dass es genauso sei, wie er sagt.

    Nö. Guckst du hier:

    Bitte melde dich an, um diesen Link zu sehen.

    Ja, da sagst Du, dass die Aussage "im Kern" doch richtig sei. Aber offenbar gibt es hier unterschiedliche Auffassungen darueber, was denn nun "der Kern" ist...

    Anscheinend. Das ist aber Haarspalterei. ;)

    Ich habe ja jetzt schon mindestens 3 mal erklÀrt, wie ich den Spruch von Dijkstra interpretiere.

  • Mir sei auch der Hinweis erlaubt, dass detlef ja nun mehrfach erklĂ€rt hat, dass er selber mit Basic eingestiegen ist und auch heute noch gelegentlich in Basic programmiert. Er gibt also seine persönliche Erfahrung wieder, die sich im provokativen Dijkstra-Zitat widerspiegelt. M.E. wird hier ein Streit vom Zaun gebrochen, dem jede Grundlage fehlt. :knuddl:

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

  • Anscheinend. Das ist aber Haarspalterei. ;)

    Nee, Haarspalterei ist das keine. Das Zitat besteht m.E. aus 2 "Kernen", der eine ist, dass BASIC eine schlechte Sprache ist, der andere, dass BASIC-Programmierer auf ewig versaut sind und nie was anderes lernen koennen. Einmal geht es also um die Sprache, das andere mal um die Personen, die sie gelernt haben - und das ist auch das "problematische" bei diesem Zitat. Daher ist aus meiner Sicht schon wichtig, klarzustellen, welcher "Kern" denn nun der ist, der als "richtig" angesehen wird.

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

  • Wenn du dich mal an einem Thema festgebissen hast. :D

    Kennt man ja von Dir zum Glueck gar nicht ;)

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

  • Leute Bitte !! Lasst jedem seine Meinung ! Wir sind doch nicht mehr 16 ?

    cool ! Danke ! Danke auch fĂŒr den Wiki Hinweis !

    also so einen compiler zu bauen - da muss ich schon sagen RESPEKT was du hier geschaffen hast ! Beachtlich - möchte nicht wissen wie viele Stunden da hineingelaufen sind....

  • ist das .IL File eine art Intel 80xx assembler mit all den Movs und JneÂŽs ?

    zum komprimieren vom Programm fÀllt mir nur mehr ein alle Texte im Spiel von der DISK aus einem SEQ File zu holen

    bzw eine art LZW zu machen die die SĂ€tze in Worte splittet und dann nur mehr vectoren auf die Worte oder wort sequenzen setzt.

    Bsp:

    .STRG "{217}ou can't do that with a car."

    .STRG "{217}ou can't climb that."

    .STRG "{217}ou can't buy it here."

    wird zu:

    *LowbyteHighbyteDo that with a car

    *LowbyteHighbyteClimb That"

    Dictonary:

    LowbyteHighbyte ; label im RAM

    .STRG "{217}ou can't"


    hier kann man die "You canÂŽt" ersetzen mit einem vectorcode und diesen dann ĂŒberall wo es vorkommt ersetzen.

    Keine Ahnung ob das Sinn macht da das Programm dadurch wieder langsamer wird. Aber man kann im Leben nich allles haben :wink:

  • ist das .IL File eine art Intel 80xx assembler mit all den Movs und JneÂŽs ?

    Ja, sieht so aus, oder? ;)

    Nee, ist es nicht wirklich. Das ist der Code in der Intermediate Language, in die MOSpeed im ersten Schritt compiliert. Erst danach wird daraus dann in die Zielsprache compiliert (hier eben in 6502-Assembler und von dort dann in echte Maschinensprache). Die ist eher spontan entstanden und ich habe wohl ein paar gedankliche Anleihen bei X86-Assembler gemacht...Absicht war das aber nicht, eher die Aktivierung von lÀngst vergessenen Gehirnregionen.

    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.