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.
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.
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.
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?
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 .
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.
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 von Whiz-zarD
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.
Ich sehe keine Art von Typisierung in irgendeinem der Beispiele, vielleicht möchtest du diesen Punkt etwas näher erläutern.
...
Hier findet eine schwache typisierung statt, da der Datentyp nicht mit angegeben wird.
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 von Cornix
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 von Cornix
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.
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 von Whiz-zarD
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.
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?