Umfrage: Bevorzugte Script Syntax

[Cornix]

Danke für die Beteiligung.

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.

[Shieru]

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.

[Cornix]

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

[Shieru]

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.

[IronChef]

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.

[Corti]

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.

[Kelven]

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?

[Liferipper]

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 .

[Whiz-zarD]

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.

[Cornix]

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.

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.

[Whiz-zarD]

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.

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.

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.

[Cornix]

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.

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.