Frage zum Wiki-Artikel „Anweisung“

[Tabellenkalk]

Hallo,

beim Lesen des verlinkten Artikels über Anweisungen in Javascript, stolpere ich mehrfach über die Verwendung des Begriffs „Seiteneffekt“. Einerseits ist das m.E. eine Falschübersetzung von „Sideeffect“, was auf deutsch mit „Nebenwirkung“ zu übersetzen ist und das ist dann andererseits im Artikelkontext so doch nicht gemeint, oder?

Wie seht ihr das?

Gruß
Kalk

[Auge]

Hallo

beim Lesen des verlinkten Artikels über Anweisungen in Javascript, stolpere ich mehrfach über die Verwendung des Begriffs „Seiteneffekt“. Einerseits ist das m.E. eine Falschübersetzung von „Sideeffect“, was auf deutsch mit „Nebenwirkung“ zu übersetzen ist und das ist dann andererseits im Artikelkontext so doch nicht gemeint, oder?

Wie seht ihr das?

Ich habe mir mal die ersten Absätze des Abschnitts Zuweisung Ausdruck als Anweisung angetan und muss konstatieren „Hä?“. Mal abgesehen von der regelrecht inflationären Verwendung des Wortes „Seiteneffekt“ ist mir absolut nicht klar, was es, in welcher Bedeutung auch immer, aussagen soll.

Nun bin ich kein JS.-Crack, aber mit diesem Text werde ich auch nie und nimmer nicht einer. 😆

Tschö, Auge

[Matthias Scharwies]

Guten Morgen,

Ich habe mir mal die ersten Absätze des Abschnitts Zuweisung Ausdruck als Anweisung angetan und muss konstatieren „Hä?“. Mal abgesehen von der regelrecht inflationären Verwendung des Wortes „Seiteneffekt“ ist mir absolut nicht klar, was es, in welcher Bedeutung auch immer, aussagen soll.

Grad auf Mastodon gefunden: https://bildung.social/@[e-mail]/113071736090906793

Ich hatte gestern sowohl den Orignal-Artikel von Stefan Münz (2oo1), die Seiten auf MDN, die Einführung in JavaScript von molily (ca. 2010) und weiteres durchgelesen. Fun fact: molily schrieb dazu 2008 diesen lesenswerten Blog-Beitrag: Geheimnisse der JavaScript-Syntax.

Interessant: Sehr schnell tauchen in den Suchergebnissen gespiegelte Versionen der alten Doku auf.

Mein Appell:

Wenn wir als Verein und als Community eine aktuelle Referenz anbieten wollen, muss die sachlich richtig, in die Tiefe gehend, aber eben auch gleichzeitig anfängergerecht und sprachlich verständlich sein. Das ist ein Spagat, der schwierig ist, aber irgendwie erreicht werden muss.

Ich lade alle herzlich ein, am Mittwoch 29.01. um 20:15 auf Discord an unserem Stammtisch über JavaScript-Tutorials und Referenzen zu diskutieren.

Herzliche Grüße

Matthias Scharwies

[Der Martin]

Moin,

beim Lesen des verlinkten Artikels über Anweisungen in Javascript, stolpere ich mehrfach über die Verwendung des Begriffs „Seiteneffekt“. Einerseits ist das m.E. eine Falschübersetzung von „Sideeffect“, was auf deutsch mit „Nebenwirkung“ zu übersetzen ist

in der Tat wird "side effect" gern als "Seiteneffekt" übersetzt, was sprachlich Unfug ist. Nebenwirkung wäre richtig.

und das ist dann andererseits im Artikelkontext so doch nicht gemeint, oder?

Doch, genau das ist gemeint: Eine Anweisung berechnet und liefert nicht nur einen Wert als Ergebnis, sondern hat "nebenher" noch andere Auswirkungen.

Einen schönen Tag noch
 Martin

[Auge]

Hallo

und das ist dann andererseits im Artikelkontext so doch nicht gemeint, oder?

Doch, genau das ist gemeint: Eine Anweisung berechnet und liefert nicht nur einen Wert als Ergebnis, sondern hat "nebenher" noch andere Auswirkungen.

Die da wären und auf welche Weise in den (Kon)-Text des Artikels passen?

Tschö, Auge

[Rolf B]

Hallo Auge,

das ist irgendwie schwierig.

"Klassisch" unterscheidet man Statements (Anweisungen) und Expressions. Statements ändern was am System oder lösen Aktionen aus, Expressions berechnen was und ändern nichts.

Aber so klassisch war es nie wirklich, und es wurde immer weiter aufgeweicht. Man fasste Statements zu Prozeduren zusammen. Man erfand Funktionen, die einen Wert haben und als Teil einer Expression verwendbar sind. Man vermischte Prozeduren und Funktionen, indem man in Funktionen Statements ausführte, die etwas am System ändern und damit Nebenwirkungen haben.

Und dann kam C das mit dem Zuweisungsoperator die Nebenwirkung zum Prinzip erhob, sowie die Prozedur abschaffte und alles Funktion nannte.

In C- und seinen Abkömmlingen ist es eher so, dass Statements etwas deklarieren bzw. definieren, oder den Programmfluss steuern. Alles andere sind Operatoren oder Aufrufe von Funktionen der Laufzeitumgebung. Wie man es aus Assembler eben kennt.

Die Folge ist, dass jeder Ausdruck das Potenzial für Nebenwirkungen hat. Er kann Variablen verändern (per Zuweisung oder In-/Dekrement) oder durch Funktionsaufrufe beliebige Aktionen anstoßen.

D.h. für ein gutes Programm braucht man Disziplin und muss darauf achten, dass Ausdrücke entweder etwas ermitteln und damit nebenwirkungsfrei sind, ODER etwas auslösen. Der Zuweisungsoperator steckt irgendwie dazwischen, weil er ja einen Wert ermitteln und dann durch die Zuweisung das System verändern muss. Hier sollte darauf geachtet werden, dass man Zuweisungen nicht dort versteckt, wo eigentlich nur ein Wert erwartet wird.

Dinge wie while ($row = $db->fetch()) sind gängige Praxis, de facto aber ein Verstoß gegen gute Programmstruktur und fallen einem in Form von if ($a = 3) auf die Füße.

Wie man das in einen Basisartikel über Anweisungen packt, ohne zu sehr in die Breite zu gehen, ist eine spannende Frage… Wer sich eine bessere Form des Artikels vorstellen kann, darf gerne einen Entwurf in seinem Benutzernamensraum des Wiki vorbereiten und vorstellen (einfach als Lemma so etwas wie Benutzer:Hugo/Anweisungen verwenden).

Rolf

[Jonathan Harker]

Hallo Der,

Moin,

beim Lesen des verlinkten Artikels über Anweisungen in Javascript, stolpere ich mehrfach über die Verwendung des Begriffs „Seiteneffekt“. Einerseits ist das m.E. eine Falschübersetzung von „Sideeffect“, was auf deutsch mit „Nebenwirkung“ zu übersetzen ist

in der Tat wird "side effect" gern als "Seiteneffekt" übersetzt, was sprachlich Unfug ist. Nebenwirkung wäre richtig.

Ja, die Wikipedia verwendet den Begriff Wirkung_(Informatik)

Manchmal wird auch von Seiteneffekt gesprochen, eine Bezeichnung, die auf eine Rückübersetzung des englischen ''side effect'' (deutsch: Nebenwirkung) zurückgeht.

Bis bald!
Jonathan

[Matthias Scharwies]

Servus!

Hallo Der,

Moin,

Ja, die Wikipedia verwendet den Begriff Wirkung_(Informatik)

Danke, habe einen Glossar-Eintrag angelegt: https://wiki.selfhtml.org/wiki/Wirkung

Herzliche Grüße

Matthias Scharwies

[JürgenB]

Hallo Matthias,

Danke, habe einen Glossar-Eintrag angelegt: https://wiki.selfhtml.org/wiki/Wirkung

du hast im Text noch zweimal den Begriff Seiteneffekt verwendet, ich habe das mal in Wirkung geändert.

Gruß
Jürgen

[Matthias Scharwies]

Servus!

Hallo Matthias,

Danke, habe einen Glossar-Eintrag angelegt: https://wiki.selfhtml.org/wiki/Wirkung

du hast im Text noch zweimal den Begriff Seiteneffekt verwendet, ich habe das mal in Wirkung geändert.

Danke! Ich bin ziemlich geflasht, dass der Begriff doch schon ein paarmal in unserem Wiki auftaucht!

Herzliche Grüße

Matthias Scharwies

[Matthias Scharwies]

Guten Morgen,

beim Lesen des verlinkten Artikels über Anweisungen in Javascript, stolpere ich mehrfach über die Verwendung des Begriffs „Seiteneffekt“. Einerseits ist das m.E. eine Falschübersetzung von „Sideeffect“,

Vielen Dank für dein Feedback - die Sprachelemente sind schon lange auf unserer internen ToDo-Liste, allerdings nur JavaScript/Datentyp mit einem sichtbaren ToDo.

Stefan Münz hatte 2002 nur kurz formuliert:

JavaScript besteht letztendlich aus einer kontrollierten Anordnung von Anweisungen. Das sind Befehle, die der JavaScript-Interpreter des WWW-Browsers bewertet und in Maschinencode umsetzt, der auf dem Rechner des Anwenders ausführbar ist.

Es gibt einfache und komplexere Anweisungen.

Zahl = 42;

Quadrat = Zahl * Zahl;

In diesem Kapitel ging es um Anweisungen, Anweisungsblöcke und auch gleich um Bezeichner und Kommentare, allerdings ohne Liste der reservierten Wörter.

MDN ist da viel spezieller:

JavaScript/Reference/Statements#difference_between_statements_and_declarations

In der deutschen automatischen Übersetzung kommt der imho auch falsche Begriff „Seiteneffekte“ vor. Der in unserem Artikel verlinkte Wikipedia-Artikel ist viel theoretischer.

Ich persönlich hatte um 2018 gedacht, dass man diese Stubs in den Einstiegs-Tutorials aufgehen lassen könnte. Mittlerweile glaube ich aber auch, dass es Grudnlagenartikel geben sollte, die auch die Hintergründe beleuchten.

Ich hatte (leider) irgendwann JavaScript/Sprachelemente/Anweisung zu JavaScript/Anweisung verkürzt, sodass es keine eigene/gute Übersichtsseite gibt. Hier im Test-Wiki habe ich einen Versuch mit Cards gestartet:

• JavaScript/Sprachelemente

Mir stellen sich folgende Fragen:

1. Sprachelemente: (Kurz)-Referenz oder Hintergrundartikel?
2. Reihenfolge? Anweisung als 1. Kapitel?
3. Inhalt
   Soll JavaScript/Anweisung als kurz Anweisung, Anweisungsblöcke einführen und dann die Sonderfälle beschreiben?
   (Ich habe grad noch JavaScript/Anweisung/Automatische_Semikolons gefunden, dass sollte in den Artikel und damit auch in Inhaltsverzeichnis und evtl. sogar in die Card?)

@Rolf B schrieb:

Wie man das in einen Basisartikel über Anweisungen packt, ohne zu sehr in die Breite zu gehen, ist eine spannende Frage…

Wer sich eine bessere Form des Artikels vorstellen kann, darf gerne einen Entwurf in seinem Benutzernamensraum des Wiki vorbereiten und vorstellen (einfach als Lemma so etwas wie Benutzer:Hugo/Anweisungen verwenden).

Evtl. könnte man mal einen Workshop machen, um Ziele und Schritte festzulegen und evtl. sogar zu verteilen?

Herzliche Grüße

Matthias Scharwies

[Matthias Scharwies]

Servus!

@Rolf B schrieb:

Wie man das in einen Basisartikel über Anweisungen packt, ohne zu sehr in die Breite zu gehen, ist eine spannende Frage…

Ich habe jetzt ein bisschen gesucht und habe mehr Fragen als zuvor!

Ich würde nach einer kurzen Einleitung diesen Satz übersetzen:

Statements are roughly equivalent to sentences in natural languages. A statement forms a complete unit of execution.^[1]

Dann müssen auf jeden Fall einige Beispiele kommen, etwa

alert('Hello world!');

const secondsInADay = 86400;

let a = b + c;

Erst nach diesen Beispielen und der Unterscheidung zwischen Anweisung und Deklarationen würde ich diesen Satz schreiben und weiter erklären:

Anweisungen können in einer einzigen Programmzeile aufgeschrieben werden, in den meisten Fällen aber auch auf mehrere Zeilen verteilt werden, um die Lesbarkeit des Programms zu verbessern. Sie können auch mehrere Anweisungen auf eine Programmzeile schreiben (sollten das aber unterlassen, weil die Lesbarkeit des Programms darunter leidet).

und danach das mit den automatisch eingefügten Semikolons.

Wer sich eine bessere Form des Artikels vorstellen kann, darf gerne einen Entwurf in seinem Benutzernamensraum des Wiki vorbereiten und vorstellen (einfach als Lemma so etwas wie Benutzer:Hugo/Anweisungen verwenden).

Und da fühle ich mich eigentlich nicht kompetent genug und würde bitten, dass das jemand mit einem Hintergrund in Programmierung erledigen könnte.

Herzliche Grüße

Matthias Scharwies

---

1. https://stackoverflow.com/questions/46351924/javascript-declarations-vs-expressions-vs-statements
   https://docs.oracle.com/javase/tutorial/java/nutsandbolts/expressions.html ↩︎

[Matthias Scharwies]

Hallo,

schaut Euch mal bitte das an:

JavaScript/Sprachelemente (Test-Wiki)
Die Cards werden (etwas gekürzt) auf der JavaScript-Portalseite eingebunden.

Das erste Kapitel der Referenz habe ich in JavaScript/Syntax umbenannt.^[1]

Es enthält jetzt den überarbeiteten Text zu Anweisungen und Anweisungsblöcken.

Zu Risiken und Nebenwirkungen … ist der Abschnitt, in dem die „Seiteneffekte“ besprochen werden. Ist er jetzt verständlich?

Das Beispiel mit der Funktion motorSteuerung() leitet auf Selbstvergebene_Namen über, was ich hier integriert habe. Wir hatten/haben sehr viele - ziemlich kurze Stubs, die in der Referenz imho die Gliederung zerschießen.

@Auge @Tabellenkalk Könntet ihr mal drüberschauen, ob das jetzt so passt?

Ich werde auch @Matthias Fulde (ex: Orlok) fragen, ob das fachlich ok ist.

Falls es keine Einwände gibt, würde ich das dann irgendwann rüberziehen.

---

Nächste Baustellen wären:

• JavaScript/Datentyp
• JavaScript/Variable

---

Hier bin ich völlig überfragt:

• Steuerzeichen_bei_Zeichenketten
  zu den Zeichenketten bei Datentyp oder zu JS/Objekte/string oder so lassen?
• Notation_numerischer_Werte
  zu Number, zu Datentyp oder gleich bei Syntax in den Anhang???

Herzliche Grüße

Matthias Scharwies

---

1. Stefan Münz hatte es allgemeine Regeln, molily Syntax-Grundlagen genannt. ↩︎

[Rolf B]

Hallo Matthias,

Auf der Sprachelemente-Seite ist die bei den Cards wieder mal der Gaul durchgegangen, vor allem bei den Operatoren. Du kannst deine Steuern auf einem Bierdeckel machen, aber nicht den ganzen Artikel auf eine Cards schreiben 😉

Auf der Operatorenkarte sollte nicht mehr stehen als

• Rechnen
• Vergleichen
• Logik
• und viel mehr

Dass es auch Bit-Operatoren und Zugriffsoperatoren und Analyseoperatoren und new und void und delete und ?: und :: und weiß der Geier was noch gibt, das findet man dann im Artikel.

Die Operatorenrangfolgeseite müsste man auffüllen, da fehlt einiges, und man könnte sie vielleicht auch "Operatoren-Index" erweitern. Wenn ich in JS ein ?. sehe und keine Ahnung habe, was das ist, kommt mir vielleicht eine Seite "Übersicht und Rangfolge" ganz recht, von wo aus dann je Operator auf die Wiki-Seite verlinkt wird, die ihn beschreibt.

Ich würde auch bei den Kontrollstrukturen erstmal "Noob-freundlich" sein und dort

• Entscheidungen treffen
• Befehle wiederholen

draufschreiben.

Zur Syntax-Seite: ich tue mich hier schwer, mich auf Anfängerniveau hinabzudenken. Die Card sollte vielleicht nicht mit "Syntax", sondern mit "Aufbau der Sprache" beschriftet sein?

Nach einigem Nachdenken kommt mir die Idee, dass man die Begrifflichkeiten vielleicht direkt mit Code-Snippets einführt.

const länge = 7
const breite = 9;

let fläche;

fläche = länge * breite;
alert(fläche);

Diese fünf Zeilen sehen simpel aus, aber dazu kann man Romane erzählen.

• Konstantendeklaration mit Initialisierung
• Variablendeklaration
• Was ist eine Variable
• Zuweisung
• einfacher Ausdruck
• Funktionsaufruf
• Der Hinweis, dass Variablen in JavaScript nicht auf bestimmte Wertearten festgelegt werden müssen, kann auch gegeben werden.

Auf Nebenwirkungen würde ich hier noch gar nicht eingehen. Statt dessen sollte man kurz erstmal auf Namen eingehen und diesen Teil gleich berichtigen. Eine Variable füße ist absolut zulässig. MDN verlinkt auf eine Unicode-Toolseite dazu. MDN sagt: \p{ID_Start} liefert 141269 von den 141271 Zeichen (äh, Codepoints), mit denen eine Variable beginnen darf (unter anderem auch der südafrikanische Klicklaut ǃ (\u01C3), nicht zu verwechseln mit ! (\u0021), mit dem man Bosheiten wie ǃa = 9; anrichten kann. Die beiden fehlenden sind _ und $.

\p{ID_Continue liefert 144541 der 144543 Zeichen, mit denen man weitermachen darf (es fehlen \u200c und \u200d, Zero Width Non-Joiner und Joiner) - aber nicht unbedingt sollte wenn man lesbaren Code erhalten will.

Für den Artikel sagt man vielleicht so: Die Daumenregel ist: Wenn ein Unicode-Zeichen für einen Buchstaben in irgendeiner Sprache dieser Welt steht, kann ein Name damit beginnen. _ und $ sind auch erlaubt. Für die folgenden Zeichen sind zusätzlich noch alle Zeichen erlaubt, die für eine Ziffer stehen. Das reicht als Daumenregel, und wer es genau wissen will, guckt auf die Unicode-Seite.

Verflixt, ich denke viel zu viel darüber nach und komme auf keinen grünen Zweig. Ich sollte mich da raushalten und am Makeover weitermachen.

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias,

Auf der Sprachelemente-Seite ist die bei den Cards wieder mal der Gaul durchgegangen, vor allem bei den Operatoren. Du kannst deine Steuern auf einem Bierdeckel machen, aber nicht den ganzen Artikel auf eine Cards schreiben 😉

He, he! Ich wollte eigentlich nur schauen, ob die Includes auch innerhalb der Cards funktionieren.

Um auf der Portalseite JavaScript nicht zu viel Platz wegzunehmen, würde ich gerne nur 6 Cards haben. Da müsste man gemeinsam hirnen, welche Struktur das alles haben sollte und wie die Cards aussehen sollen. Ein gutes Icon würde da schon viel Text überflüssig machen. Lass' uns da am 29.01. ddrüber sprechen.

---

Zur Syntax-Seite: ich tue mich hier schwer, mich auf Anfängerniveau hinabzudenken. Die Card sollte vielleicht nicht mit "Syntax", sondern mit "Aufbau der Sprache" beschriftet sein?

Ja, evtl.

Nach einigem Nachdenken kommt mir die Idee, dass man die Begrifflichkeiten vielleicht direkt mit Code-Snippets einführt.

const länge = 7
const breite = 9;

let fläche;

fläche = länge * breite;
alert(fläche);

Diese fünf Zeilen sehen simpel aus, aber dazu kann man Romane erzählen.

• Konstantendeklaration mit Initialisierung
• Variablendeklaration
• Was ist eine Variable
• Zuweisung
• einfacher Ausdruck
• Funktionsaufruf
• Der Hinweis, dass Variablen in JavaScript nicht auf bestimmte Wertearten festgelegt werden müssen, kann auch gegeben werden.

Ja, aber da soll es ja um Anweisung und Anweisungsblöcke gehen. Es gibt ein eigenes Kapitel zu Variablen und eins zu Funktionen.

Bis jetzt geht der Artikel ja so los - ohne Beispiel und mit gedoppeltem Text:

In JavaScript kann eine Anweisung eine Deklaration sein, ein 
Ausdruck oder eine Kontrollstruktur (Verzweigungen und Schleifen). 

[...]
Deklarationen können sich auf Variablen, Funktionen oder Klassen 
beziehen, wozu es eigene Artikel gibt. Die Kontrollstrukturen 
besprechen wir in den beiden folgenden Artikeln. 

Dann kommt gleich das Kapitel == Das Semikolon ==

Auf Nebenwirkungen würde ich hier noch gar nicht eingehen. Statt dessen sollte man kurz erstmal auf Namen eingehen und diesen Teil gleich berichtigen. Eine Variable füße ist absolut zulässig. MDN verlinkt auf eine Unicode-Toolseite dazu. MDN sagt: \p{ID_Start} liefert 141269 von den 141271 Zeichen (äh, Codepoints), mit denen eine Variable beginnen darf (unter anderem auch der südafrikanische Klicklaut ǃ (\u01C3), nicht zu verwechseln mit ! (\u0021), mit dem man Bosheiten wie ǃa = 9; anrichten kann. Die beiden fehlenden sind _ und $.

\p{ID_Continue liefert 144541 der 144543 Zeichen, mit denen man weitermachen darf (es fehlen \u200c und \u200d, Zero Width Non-Joiner und Joiner) - aber nicht unbedingt sollte wenn man lesbaren Code erhalten will.

Für den Artikel sagt man vielleicht so: Die Daumenregel ist: Wenn ein Unicode-Zeichen für einen Buchstaben in irgendeiner Sprache dieser Welt steht, kann ein Name damit beginnen. _ und $ sind auch erlaubt. Für die folgenden Zeichen sind zusätzlich noch alle Zeichen erlaubt, die für eine Ziffer stehen. Das reicht als Daumenregel, und wer es genau wissen will, guckt auf die Unicode-Seite.

Ja, das hat dir der nix eingeflüstert, der Klassen mit Smileys hatte. Mir ist das aber zuwider, weil's eben keine sprechenden Namen sind! - Das werd' ich morgen aktualisieren.

Verflixt, ich denke viel zu viel darüber nach und komme auf keinen grünen Zweig. Ich sollte mich da raushalten und am Makeover weitermachen.

😀 Schönen Feierabend!

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@Rolf B

Auf Nebenwirkungen würde ich hier noch gar nicht eingehen. Statt dessen sollte man kurz erstmal auf Namen eingehen und diesen Teil gleich berichtigen. Eine Variable füße ist absolut zulässig. MDN verlinkt auf eine Unicode-Toolseite dazu. MDN sagt: \p{ID_Start} liefert 141269 von den 141271 Zeichen (äh, Codepoints), mit denen eine Variable beginnen darf (unter anderem auch der südafrikanische Klicklaut ǃ (\u01C3), nicht zu verwechseln mit ! (\u0021), mit dem man Bosheiten wie ǃa = 9; anrichten kann.

Noch boshafter finde ich а als Variablennamen.

Ihr seht, was daran boshaft ist? Nein? Eben! Es ist ein kyrillisches а.

Kwakoni Yiquan

[MudGuard]

Hi,

Noch boshafter finde ich а als Variablennamen.

Ihr seht, was daran boshaft ist? Nein? Eben! Es ist ein kyrillisches а.

so richtig fies wird's erst dann, wenn man zusätzlich noch eine Variable mit lateinischem a (und ggf. weitere mit gleich aussehenden Zeichen) hat …

cu,
Andreas a/k/a MudGuard