Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 20 von 35

Thema: Umfrage: Bevorzugte Script Syntax

  1. #1

    Umfrage: Bevorzugte Script Syntax

    Hallo Community.

    Ich habe eine kleine Umfrage an alle im Zuge meines eigenen Game-Maker Projektes. Allerdings bezieht sich diese Umfrage nicht speziell auf meine Software sondern um Maker im Allgemeinen, deshalb ein neuer separater Thread. Möglicherweise können ja auch andere Personen einen Nutzen aus dieser Umfrage ziehen.
    Ich hoffe auch, dass ich vielleicht eine kleine Forum unterstütze Umfrage von einem Moderator eingerichtet bekommen kann, das wäre sehr freundlich.

    Diese Umfrage ist hauptsächlich für Entwickler gedacht, welche nicht programmieren können. Andere dürfen natürlich auch Antworten, aber die Meinungen der Nicht-Programmierer interessieren mich persönlich hier am meisten.

    Die Frage lautet:
    Wenn ihr ein Script für ein Spiel schreibt (RPG-Maker: Event-Pages, Common-Events, Ruby-Script, etc) habt ihr dann lieber eine langatmige Syntax mit vielen Wörtern, oder lieber etwas kurz und prägnantes mit vielen Symbolen?



    Beispiele:


    In den folgenden Beispielen soll eine Liste von Zahlen erstellt werden und dann alle Zahlen nacheinander ausgegeben werden.
    Man kann die Abfolge grob wie folgt beschreiben:
    1) Eine Liste erstellen
    2) Zahlen in die Liste einfügen
    3) Alle Zahlen ausgeben


    Kurz und prägnant, viele Symbole:
    Code:
    liste = []
    liste << 5
    liste << 8
    liste << 3.6
    
    for elem : liste {
        print elem
    }
    Viel Text, weniger Symbole:
    Code:
    liste = new List
    liste add 5
    liste add 8
    liste add 3.6
    
    for elem in liste
        print elem
    end
    Sehr viel Text; Programmcode wie Prosa:
    Code:
    set liste = new List
    add 5 to liste
    add 8 to liste
    add 3.6 to liste
    
    for each element elem in liste do
        print elem
    end for



    Meine Persönliche Meinung:

    Vorteile von mehr Text und weniger Symbolen:


    1. Für Anfänger einfacher verständlich, da die Bedeutung der Symbole nicht ersteinmal gelernt werden müssen
    2. Code liest sich einfach herunter und veranlasst zu ordentlichen Variablennamen
    3. Weniger Symbole bedeutet weniger obskure Tasten auf der Tastatur drücken die Möglicherweise nur über "shift", "alt" oder "alt-shift" erreichbar sind


    Nachteile von mehr Text und weniger Symbolen:
    1. Aufgeblähten Code, im schlimmsten Fall eine Wall-Of-Text
    2. Unüblich für erfahrene Programmierer da es nicht dem derzeitigen Standard entspricht
    3. Mehr Schreibaufwand und Leseaufwand
    4. Weniger International: Symbole können in jeder Sprache verstanden werden, englische Wörter nicht ganz so gut




    Falls ihr eher für die Wörter anstatt für Symbole tendiert, wann würdet ihr dann den Schlussstrich ziehen?
    Rechenoperationen:
    " + " => plus
    " - " => minus
    " * " => multiply
    " / " => divide
    " % " => modulo

    Vergleichsoperatoren:
    " < " => less then
    " > " => greater then
    " <= " => less then or equal
    " >= " => greater then or equal
    " == " => equal
    " != " => not equal

    Logische Operatoren:
    " & " => and
    " | " => or
    " ^ " => either or
    " ! " => invert



    Falls ihr antwortet, dann wäre es nett falls ihr auch dazu sagt, ob ihr bereits Erfahrung mit Programmiersprachen habt oder nicht.
    Vielen Dank für die Zeit und Mithilfe.

    Geändert von Cornix (05.02.2014 um 14:24 Uhr)

  2. #2
    Ich fände eine Zwischenlösung zwischen dem ersten und dem zweiten Beispiel gut.
    Vergleichs- und Rechenoperatoren sollte eigentlich jeder aus der Schule kennen, zumal "greater then or equal" ein ziemlicher Brocken ist, der auch zu Tippfehlern einlädt. Logische Operatoren dagegen würde ich ausschreiben lassen, da nicht jeder die Symbole für sie kennt, oder wenn, dann nicht unbedingt diese. Ich habe etwa sowohl in der Schule als auch in der Uni gelernt, dass " ^ " => und, " v " => oder, etc., aber vermutlich gibt es da einfach verschiedene Notationen je nach Fachgebiet.
    Auch sowas wie der add-Befehl aus dem ersten Beispiel würde mir zumindest Anfangs Probleme bereiten, da ich bei diesen Zeichen zunächst an "kleiner als" denke (ist zwar eigentlich <=, aber es sieht für mich als Laien erst einmal sehr ähnlich aus).

    Ich habe kaum Erfahrung in Sachen Programmiersprachen - ich finde sowas zwar interessant und habe mir hin und wieder mal was angeguckt, aber da ist kaum etwas hängen geblieben. Ich kann etwas HTML und CSS, wo ich beispielsweise das Einrücken, die { }-Klammern als klares Zeichen für einen zusammengehörenden "Block" (sozusagen) und auch das Semikolon als Zeichen für das Ende eines Befehls sehr praktisch finde. Man muss sich zwar dran gewöhnen, aber ich finde es erleichtert es ungemein, später sein Geschriebsel noch zu verstehen und dabei einen Sinn dafür zu bekommen, welche Funktionen diese Zeichen für das Ausführen nun haben.

    Es wäre natürlich toll, wenn die Zeichen echt nur eine Funktion hätten, möglichst kontextunabhängig. Wenn ich etwa eckige Klammern im Eventcode vom Maker sehe weiß ich, dass hier ein Parameter kommt, egal welche Zeile ich mir gerade ansehe. Bei deinem Beispiel habe ich da das Problem, dass "<=" und "<<" bzw. "!=" und "!" oberflächlich betrachtet völlig verschiedene Dinge tun.

  3. #3
    Ich kann programmieren und bevorzuge die Syntax der gängigen höheren Programmiersprachen gegenüber der textgewaltigen Variante. Zu viele Verkürzungen (s. reguläre Ausdrücke) finde ich allerdings auch unleserlich.

    Zitat Zitat
    Bei deinem Beispiel habe ich da das Problem, dass "<=" und "<<" bzw. "!=" und "!" oberflächlich betrachtet völlig verschiedene Dinge tun.
    Die ersten beiden tun das nicht nur oberflächlich betrachtet, zumindest wenn man C++ zugrunde legt. Das Ausrufezeichen kannst du aber als "Nicht" interpretieren, also "nicht gleich" bzw. "nicht" gefolgt von einem größeren Ausdruck. Gerade bei den logischen Operationen könnte ich mir vorstellen, dass jemand ohne Programmiersprache auch mit Wörtern wie and Probleme hätte.

  4. #4
    Danke für die Beteiligung.

    Zitat Zitat von BDraw Beitrag anzeigen
    Ich fände eine Zwischenlösung zwischen dem ersten und dem zweiten Beispiel gut.
    Vergleichs- und Rechenoperatoren sollte eigentlich jeder aus der Schule kennen, zumal "greater then or equal" ein ziemlicher Brocken ist, der auch zu Tippfehlern einlädt. Logische Operatoren dagegen würde ich ausschreiben lassen, da nicht jeder die Symbole für sie kennt, oder wenn, dann nicht unbedingt diese. Ich habe etwa sowohl in der Schule als auch in der Uni gelernt, dass " ^ " => und, " v " => oder, etc., aber vermutlich gibt es da einfach verschiedene Notationen je nach Fachgebiet.
    Auch sowas wie der add-Befehl aus dem ersten Beispiel würde mir zumindest Anfangs Probleme bereiten, da ich bei diesen Zeichen zunächst an "kleiner als" denke (ist zwar eigentlich <=, aber es sieht für mich als Laien erst einmal sehr ähnlich aus).

    Es wäre natürlich toll, wenn die Zeichen echt nur eine Funktion hätten, möglichst kontextunabhängig. Wenn ich etwa eckige Klammern im Eventcode vom Maker sehe weiß ich, dass hier ein Parameter kommt, egal welche Zeile ich mir gerade ansehe. Bei deinem Beispiel habe ich da das Problem, dass "<=" und "<<" bzw. "!=" und "!" oberflächlich betrachtet völlig verschiedene Dinge tun.
    Falls es interessiert: die Syntax der Beispiele ist aus existierenden Programmiersprachen genommen, nichts davon kommt von mir; aber auch nicht alles aus der selben Sprache.

  5. #5
    Ich würde eine extrem kurze Syntax verwenden, und dafür lieber die Möglichkeit bieten, Klicki-Bunti-Plugins erstellen zu können, die den ganzen Prozess abkürzen können (die zu verwenden würde dann nämlich auch keine rechtlichen Probleme geben, wenn man sein Spiel verkaufen möchte (vorausgesetzt, du bietest so eine Lizenz an)).

    Das wäre doch auch mal eine tolle Idee für einen Maker - KOMPLETT Skriptbasiert, aber eine grafische Oberfläche wird nicht nur mitgeliefert, sondern auch noch eine Schnittstelle, die es ermöglicht, besagte Oberfläche nach Gutdünken zu erweitern. So kann man sich langsam reinlernen und seine Arbeitsweise optimieren. Stellt man später fest, dass man einen bestimmten Teil der Oberfläche nicht mehr braucht und mit dem Texteditor schneller arbeitet kann man das auch.

  6. #6
    Das ist zwar ein interessantes Gedankenexperiment, es entspricht aber leider nicht meiner Zielsetzung für das Projekt.

  7. #7
    Zitat Zitat von Cornix Beitrag anzeigen
    Das ist zwar ein interessantes Gedankenexperiment, es entspricht aber leider nicht meiner Zielsetzung für das Projekt.


    In dem Fall will ich nichts gesagt haben.

  8. #8
    Ich würde da ehrlich gesagt die Variante "Programmcode wie Prosa" bevorzugen. Zum einen erscheint sie mir, als jemand der nicht wirklich programmieren kann (das was ich an Ruby Skripten für mein Spiel erstell würd ich eher als Basteln mit hohem Trial&Error-Anteil bezeichnen ^^), am eingängigsten und ich persönlich kann mich in eine Struktur die nicht zu stark auf Symbole und Verkürzungen setzt auch schneller wieder einfinden wenn ich mich mal eine Zeit nicht damit auseinandergesetzt hab, was für mich persönlich relativ wichtig ist, da ich eher sporadisch an Skripten arbeite und auch außerhalb des Makers überhaupt keinen Bezug zu Programmiersprachen hab.

    Die Rechen- und Vergleichoperatoren find ich übrigens recht eingängig und gut, da ich persönlcih die Schreibweise auch aus anderen bereichen gewohnt bin. Bei den Logischen Operatoren finde ich das ganze ausgeschrieben eingängiger.

    Geändert von IronChef (05.02.2014 um 02:21 Uhr)

  9. #9
    Die C-artige Bit-shift-syntax als Synonym für "Fügt der Liste hinzu" find eich unoptimal. Ich würde da klare Begriffe vorziehen. zB ist "append" klarer als "add", da ja keine Addition stattfindet.

  10. #10
    Wobei add in der ich sage mal Standardsprache ja auch hinzufügen bedeutet, Addition wird daraus nur in der Mathematik. append ist für die Englisch-Herausgeforderten vermutlich schwerer zu verstehen. Für die wären deutsche Begriffe natürlich am besten, aber ich nehme mal an, dass die Sprache "international" sein soll, oder?

  11. #11
    Auch als jemand der einigermaßen Ahnung von Programmierung hat, würde ich sagen, dass mir die letzte Version am besten gefällt, schlicht und ergreifend, weil man am schnellsten und mit dem wenigsten Nachdenken erkennt, was jeder Befehl tut, und man so beim Überarbeiten/Fehlerkorrigieren/Ändern am schnellsten vorankommt. Mag aber auch daran liegen, dass ich idR zu faul zum ordentlichen Kommentieren bin .

  12. #12
    Das letzte Beispiel ist inkonsequent. Es ist eine Mischung aus schwacher-, und starker Typisierung.
    Das erste Beispiel ist suboptimal, da << idR eine Bitverschiebung einleitet. Auch denke ich nicht, dass ein Anfänger weiß, was [] bedeutet.

    Das zweite Beispiel sieht schon deutlich besser aus.

  13. #13
    Zitat Zitat von Whiz-zarD Beitrag anzeigen
    Das letzte Beispiel ist inkonsequent. Es ist eine Mischung aus schwacher-, und starker Typisierung.
    Ich sehe keine Art von Typisierung in irgendeinem der Beispiele, vielleicht möchtest du diesen Punkt etwas näher erläutern.

    Zitat Zitat von Whiz-zarD Beitrag anzeigen
    Das erste Beispiel ist suboptimal, da << idR eine Bitverschiebung einleitet. Auch denke ich nicht, dass ein Anfänger weiß, was [] bedeutet.
    Der Operator " << " ist nur in manchen Sprachen eine Bitverschiebung, allgemein hat er keine feste Definition. Jede Sprache kann ihre Syntax frei wählen und das Beispiel ist nichts weiter als ein Beispiel für eine minimale Syntax.

    Die Definition von Listen in Ruby mit dem Schlüsselsymbol " [] " und von Hash-Maps mit " {} " ist ebenfalls nicht geläufig in anderen Programmiersprachen und meiner Meinung nach gleichwertig verwirrend.

  14. #14
    Zitat Zitat von Cornix Beitrag anzeigen
    Ich sehe keine Art von Typisierung in irgendeinem der Beispiele, vielleicht möchtest du diesen Punkt etwas näher erläutern.
    Code:
    set liste = new List
    add 5 to liste
    add 8 to liste
    add 3.6 to liste
    Hier findet eine schwache typisierung statt, da der Datentyp nicht mit angegeben wird.

    Code:
    for each element elem in liste do
        print elem
    end for
    Das element kann man als eine starke Typisierung interpretieren, indem liste nur Daten speichert vom Typ element.
    Das ist wohl so nicht gemeint, aber das ist verwirrend.

    Zitat Zitat von Cornix Beitrag anzeigen
    Der Operator " << " ist nur in manchen Sprachen eine Bitverschiebung, allgemein hat er keine feste Definition. Jede Sprache kann ihre Syntax frei wählen und das Beispiel ist nichts weiter als ein Beispiel für eine minimale Syntax.
    In allen gängigen Sprachen ist das eine Bitverschiebung. Mir geht es schon bei C++ auf den Sack, dass sie den <<-Operator für die Streams überladen haben, da ich finde, dass dies nicht zur Lesbarkeit beigetragen hat.

    Zitat Zitat von Cornix Beitrag anzeigen
    Die Definition von Listen in Ruby mit dem Schlüsselsymbol " [] " und von Hash-Maps mit " {} " ist ebenfalls nicht geläufig in anderen Programmiersprachen und meiner Meinung nach gleichwertig verwirrend.
    Die Entwickler von Ruby haben es sich aber nicht zur Aufgabe gemacht, eine Skriptsprache für Anfänger zu entwickeln.

  15. #15
    Zitat Zitat von Whiz-zarD Beitrag anzeigen
    Das element kann man als eine starke Typisierung interpretieren, indem liste nur Daten speichert vom Typ element.
    Das ist wohl so nicht gemeint, aber das ist verwirrend.
    Das könnte man vielleicht so interpretieren wenn man sich die API der Listen-Klasse durchliest und dort darauf hingewiesen wird; allerdings glaube ich nicht, dass jemand, der niemals programmiert hat, es so interpretieren würde.

    Zitat Zitat von Whiz-zarD Beitrag anzeigen
    Mir geht es schon bei C++ auf den Sack, dass sie den <<-Operator für die Streams überladen haben, da ich finde, dass dies nicht zur Lesbarkeit beigetragen hat.

    Die Entwickler von Ruby haben es sich aber nicht zur Aufgabe gemacht, eine Skriptsprache für Anfänger zu entwickeln.
    Ich hoffe das war sarkastisch gemeint und die Doppelmoral ist dir offensichtlich. Im Internet ist soetwas immer so schwer zu unterscheiden.

  16. #16
    Zitat Zitat von Cornix Beitrag anzeigen
    Ich hoffe das war sarkastisch gemeint und die Doppelmoral ist dir offensichtlich. Im Internet ist soetwas immer so schwer zu unterscheiden.
    Wieso Sarkasmus?
    Du machst hier Vergleiche mit Ruby, und ich habe nicht gesagt, dass ich Ruby toll finde.
    Sicherlich ist [] und {} verwirrend, und ich bin davon auch kein Fan, aber Ruby und C++ ist nicht für Anfänger gedacht, und was schon für erfahrene Entwickler verwirrend klingt, klingt für einen Anfänger erst recht verwirrend. Wieso also solche Sprachkonstrukte benutzen, wenn die Sprache primär für Anfänger gedacht ist?

  17. #17
    Zitat Zitat von Cornix Beitrag anzeigen
    Diese Umfrage ist hauptsächlich für Entwickler gedacht, welche nicht programmieren können. Andere dürfen natürlich auch Antworten, aber die Meinungen der Nicht-Programmierer interessieren mich persönlich hier am meisten.
    Du sagst, die Umfrage ist für Leute, die nicht programmieren können, haust aber gleich so viele Sachen raus die jemand, der wirklich nicht programmieren kann, überhaupt nicht versteht.
    Ich versteh z.B. relativ wenig, weil ich keine Programmiersprache kenne.
    Was ich kenne. Die Events des RPG-Makers. Das sind ja noch relativ einfache Sachen, weil einem da etwas vorgegeben wird.
    Aber so etwas selber schreiben. Das wird viele überfordern

    Wenn so etwas nicht verwendet wird, schränkt das zwar vieles ein, ist aber dann einem größeren Publikum zugänglich ^^

  18. #18
    @Cornix:
    Ich bin etwas irritiert. Zwar veranstaltest du hier ein Topic in der du Meinung einforderst, wenns das aber jemand tut, wehrst du dich mit Händen und Füßen dagegen. Auch wenn dein Maker für Nicht-Programmierer ist, in der Praxis liegt der Nutzer wahrscheinlich eher irgendwo zwischen Nichtskönner und Profi, von daher halte ich es für eine gute Sache, zumindest drauf zu achten keine allgemeinen Konventionen zu brechen (siehe Bitweises << ), weil das halt mehr verwirrt als Klarheit verschafft. Niemand erwartet, dass du die ultimative Scirptsyntax herbeizauberst, aber darum gibt es ja dieses Topic, wenn man dir Tipps gibt, was man missverstehen könnte, dann nimm die Tipps doch an.

  19. #19
    Zitat Zitat von Corti Beitrag anzeigen
    @Cornix:
    Ich bin etwas irritiert. Zwar veranstaltest du hier ein Topic in der du Meinung einforderst, wenns das aber jemand tut, wehrst du dich mit Händen und Füßen dagegen.
    Und ich hatte schon gedacht, ich wäre der einzige, der dieses Gefühl hat.

  20. #20
    Zitat Zitat von Whiz-zarD Beitrag anzeigen
    Wieso Sarkasmus?
    Du machst hier Vergleiche mit Ruby, und ich habe nicht gesagt, dass ich Ruby toll finde.
    Sicherlich ist [] und {} verwirrend, und ich bin davon auch kein Fan, aber Ruby und C++ ist nicht für Anfänger gedacht, und was schon für erfahrene Entwickler verwirrend klingt, klingt für einen Anfänger erst recht verwirrend. Wieso also solche Sprachkonstrukte benutzen, wenn die Sprache primär für Anfänger gedacht ist?
    Dann habe ich dich vielleicht falsch verstanden. Es sah für mich sehr stark danach aus, als ob du diese Entscheidung unterstützt hättest, auch wenn du es nicht wörtlich gesagt hast.

    Zitat Zitat von Schnorro Beitrag anzeigen
    Du sagst, die Umfrage ist für Leute, die nicht programmieren können, haust aber gleich so viele Sachen raus die jemand, der wirklich nicht programmieren kann, überhaupt nicht versteht.
    Ich versteh z.B. relativ wenig, weil ich keine Programmiersprache kenne.
    Bitte erläutere was genau du nicht verstehst und ich werde mir Mühe geben es besser zu formulieren.

    Zitat Zitat von Schnorro Beitrag anzeigen
    Was ich kenne. Die Events des RPG-Makers. Das sind ja noch relativ einfache Sachen, weil einem da etwas vorgegeben wird.
    Aber so etwas selber schreiben. Das wird viele überfordern
    Ich habe ebenfalls vor die Scripte per Click-GUI erstellen zu lassen. Dementsprechend muss niemand diese Scripte selber schreiben, es geht mir hier nur um die Verständlichkeit.

    Zitat Zitat von Corti Beitrag anzeigen
    @Cornix:
    Ich bin etwas irritiert. Zwar veranstaltest du hier ein Topic in der du Meinung einforderst, wenns das aber jemand tut, wehrst du dich mit Händen und Füßen dagegen.
    Ich wehre mich nicht gegen Meinungen, ich kommentiere sie nur mit meiner eigenen. Das bedeutet nicht, dass ich die Meinungen der anderen ignoriere oder nicht beachte.

    Zitat Zitat von Corti Beitrag anzeigen
    Auch wenn dein Maker für Nicht-Programmierer ist, in der Praxis liegt der Nutzer wahrscheinlich eher irgendwo zwischen Nichtskönner und Profi, von daher halte ich es für eine gute Sache, zumindest drauf zu achten keine allgemeinen Konventionen zu brechen (siehe Bitweises << ), weil das halt mehr verwirrt als Klarheit verschafft. Niemand erwartet, dass du die ultimative Scirptsyntax herbeizauberst, aber darum gibt es ja dieses Topic, wenn man dir Tipps gibt, was man missverstehen könnte, dann nimm die Tipps doch an.
    Die Beispiele waren keine Beispiele für eine Script-Syntax, welche ich wirklich verwenden würde. Keine 10 Pferde würden mich dazu reiten einen Operator wie " << " zu definieren; nichteinmal für bitweise Verschiebung.
    Es sollen lediglich Beispiele für Syntax mit starkem Fokus auf Symbolik und starkem Fokus auf Text sein.
    Keines des Beispiele stellt eine Syntax dar, welche ich tatsächlich in Erwägung ziehe. Sie dienen nur dem Zweck der Umfrage.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •