Pourquoi l'opérateur d'assignation affecte-t-il le côté gauche?

J'ai commencé à enseigner la programmation à un ami tout récemment (nous utilisons Python) et lorsque nous avons commencé à discuter de la création de variables et de l'opérateur d'affectation, elle a demandé pourquoi la valeur à droite est attribuée au nom à gauche et non l'inverse. .

Je n'y avais pas trop réfléchi auparavant, parce que cela me semblait naturel, mais elle a dit que la gauche à droite lui paraissait plus naturelle, car c'est ainsi que la plupart d'entre nous lisons les langues naturelles.

J'y ai pensé et j'ai conclu que cela rend le code beaucoup plus facile à lire, car les noms attribués (que le programmeur devra réutiliser) sont facilement visibles, alignés à gauche.

aligned = 2
on = 'foo' + 'bar' + 'foobar'
the = 5.0 / 2
left = 2 + 5

Par opposition à:

2 = aligned 
'foo' + 'bar' + 'foobar' = on
5.0 / 2 = the 
2 + 5 = right 

# What were the names again...?

Maintenant, je me demande s’il existe également d’autres raisons à cette norme. Y a-t-il une histoire derrière cela? Ou y a-t-il une raison technique pour laquelle c'est une bonne option (je ne connais pas beaucoup les compilateurs)? Et y a-t-il des langages de programmation qui assignent au côté droit?

Idem @paxdiablo. Les premiers langages de programmation ont été écrits par des mathématiciens - en réalité, ils l'ont tous été. En mathématiques, selon son propre principe - lire de gauche à droite - cela a du sens dans son fonctionnement.

x = 2y - 4.

En mathématiques, vous diriez ceci: Soit x égal à 2y -4.

Aussi, même en algèbre, vous le faites. Lorsque vous résolvez une équation pour une variable, vous isolez la variable que vous résolvez pour le côté gauche. c'est-à-dire que y = mx + b;

En outre, une fois que toute une famille de langues - telle que la famille C - a une certaine syntaxe, il est plus coûteux de la modifier.

BASIC, l’un des premiers langages informatiques avait la forme "appropriée" de:

10 LET AREA = HEIGHT * WIDTH

qui correspond à la mentalité mathématique consistant à spécifier une variable, telle que "Soit H la hauteur de l'objet".

COBOLétait également similaire avec sa COMPUTEdéclaration. Comme pour de nombreuses façons de faire, il s’agissait peut-être simplement d’une décision arbitraire adoptée dans de nombreuses langues.

En fait, il existe un langage de programmation qui assigne sur le côté droit: TI-BASIC ! Non seulement cela, mais il n'utilise pas non plus '=' en tant qu'opérateur d'affectation, mais utilise plutôt une flèche appelée opérateur "STO".

exemples:

5→A
(A + 3)→B
(A - B)→C

Dans l'exemple ci-dessus, trois variables sont déclarées et reçoivent des valeurs. A serait 5, B serait 8 et C serait -3. La première déclaration / assignation peut être lue 'stocker 5 en tant que A'.

Quant à savoir pourquoi TI-BASIC utilise un tel système pour les affectations, je l’attribue à l’être, car c’est un langage de programmation pour une calculatrice. L'opérateur "STO" sur les calculatrices TI était le plus souvent utilisé dans les opérations normales de calculatrice après le calcul d' un nombre. S'il s'agissait d'un numéro que l'utilisateur souhaitait mémoriser, il appuierait sur le bouton "STO" et le calculateur l'inviterait à entrer un nom (enclenchant automatiquement le verrou alpha pour que les frappes au clavier produisent des lettres au lieu de chiffres):

Sin(7 + Cos(3))
                    -.26979276
Ans→{variable name}
                    -.26979276

et l'utilisateur peut nommer la variable comme bon leur semble. Avoir à activer le verrou alpha, taper le nom, puis appuyer sur "STO", et appuyer sur la touche "Ans" aurait été beaucoup trop fastidieux pour des opérations normales. Toutes les fonctions de la calculatrice étant disponibles dans TI-BASIC, aucun autre opérateur d'affectation n'a été ajouté car "STO" effectuait la même tâche, même à l'inverse de la plupart des autres langues.

(Anecdote: TI-BASIC a été l’une des premières langues que j’ai apprise. J’ai donc eu l’impression d’attribuer la valeur LEFT à la gauche, ce qui était inhabituel et «à l’arrière»!

Heuristique 1: lorsque vous concevez un langage, vous devez choisir le plus commun, le plus intuitif, sinon vous obtiendrez Perl +.

Maintenant, comment est-ce plus naturel (du moins pour un anglophone)? Regardons comment nous écrivons / disons des choses en anglais:

Steven a maintenant 10 ans (contrairement à Steven, il a maintenant 10 ans). Je pèse plus de 190 livres (au lieu de plus de 190 livres).

Dans du code:

steven = 10
i > 190

Ce qui suit semble aussi plus naturel:

"Si Marie a 18 ans, elle peut avoir un bonbon". "Si j'ai moins de 21 ans, je demanderai à mon frère de tequila".

if (mary == 18) { ... }
if (i < 21) { ... }

que:

"Si Marie a 18 ans ..." "Si 21 ans est plus grande que mon âge ..."

Maintenant le code:

if (18 == mary) { ... }
if (21 > i) { ... }

Notez que cela n’est naturel ni pour les programmeurs ni pour les anglophones. Les phrases ressemblent à du yoda, et le code est surnommé yoda-conditions. Celles-ci pourraient être utiles en C ++, mais je suis sûr que la plupart des gens seront d’accord: si un compilateur pouvait faire le gros du travail et alléger le besoin de conditions yoda, la vie serait un peu plus facile.

Bien sûr, on peut s'habituer à n'importe quoi. Par exemple, le numéro 81 est écrit comme suit:

Quatre-vingt un (anglais) Quatre-vingt et un (espagnol) Un et quatre-vingt (allemand).

Enfin, il y en a 4! = 24 façons valables de dire "pomme verte se trouve sur la table" en russe - l'ordre (ou presque) n'a pas d'importance, sauf que "on" doit être associé à "table". Ainsi, si vous parlez russe (par exemple), vous ne voudrez peut-être pas écrire a = 10ou 10 = aque les deux semblent également naturels.

Bien que la linguistique soit un sujet fascinant, je ne l'ai jamais étudié formellement et ne connais pas beaucoup de langues. J'espère cependant avoir fourni suffisamment de contre-exemples.

Cela a commencé avec FORTRAN dans les années 1950. Où FORTRAN était une abréviation de FORmula TRANslation - les formules en question étant de simples équations algébriques qui, par convention, sont toujours assignées à gauche.

De son côté, son COBOL presque contemporain était censé être de type anglais et assigné à droite (la plupart du temps!).

MOVE 1 TO COUNTER.
ADD +1 TO LINE-CNT.
MULTIPLY QTY BY PRICE GIVING ITEM-PRICE.

Eh bien, comme @ diceguyd30 l'a fait remarquer, il y a les deux notations.

• <Identifier> = <Value>signifie "que l' identifiant soit une valeur ". Ou pour développer cela: Définissez (ou redéfinissez) la variable Identifier to Value .
• <Value> -> <Identifier>signifie "stocker la valeur à l' identificateur ". Ou pour développer cela: Mettez Value à l'emplacement désigné par Identifier .

Bien sûr, en règle générale, l' identificateur peut être une valeur L quelconque.

La première approche respecte le concept abstrait de variables, la seconde approche davantage le stockage réel.

Notez que la première approche est également courante dans les langues, sans affectation. Notez également que la définition des variables et l' affectation sont relativement proches par <Type> <Identifier> = <Value>rapport <Identifier> = <Value>.

Comme cela a déjà été mentionné, pratiquement tous les premiers langages informatiques fonctionnaient de cette façon. Par exemple, FORTRAN, qui est arrivé bien des années avant BASIC.

En fait, il est très logique d’avoir la variable assignée à gauche de l’expression d’affectation. Dans certaines langues, vous pouvez avoir plusieurs routines surchargées différentes avec SAME NAME, renvoyant différents types de résultats. En laissant le compilateur voir d’abord le type de la variable affectée, il sait quelle routine surchargée appeler ou quelle distribution implicite générer lors de la conversion (par exemple) d’un entier en un flottant. C'est une explication un peu simpliste, mais j'espère que vous aurez l'idée.

Cela pourrait être un vestige des premiers algorithmes d'analyse. Rappelez-vous que l'analyse syntaxique de LR n'a été inventée qu'en 1965 et qu'il est fort possible que les analyseurs syntaxiques de LL aient eu des problèmes (dans les limites de temps et d'espace des machines à l'époque) qui tournent à l'inverse. Considérer:

identifier = function();
function();

Les deux sont clairement distingués du deuxième jeton. D'autre part,

function() = identifier;
function();

Pas drôle. Cela empire lorsque vous commencez à imbriquer des expressions d'affectation.

function(prev_identifier = expression) = identifier;
function(prev_identifier = expression);

Bien sûr, plus facile à comprendre pour des machines signifie également plus facile à comprendre pour des humains. Un autre exemple simple consisterait à rechercher l’initialisation d’un identifiant donné.

identifier1 = expressionOfAnArbitraryLength;
identifier2 = expressionOfAReallyReallyReallyArbitraryLength;
identifier3 = expression;
identifier4 = AlongLineExpressionWithAFunctionCallWithAssignment(
    identifier = expr);

Facile, il suffit de regarder le côté gauche. Côté droit, d'autre part

expressionOfAnArbitraryLength = identifier1;
expressionOfAReallyReallyReallyArbitraryLength = identifier2;
expression = identifier3;
AlongLineExpressionWithAFunctionCallWithAssignment(expr = identifier
    ) = identifier4;

Surtout quand vous ne pouvez pas grepperforer les cartes, il est beaucoup plus difficile de trouver l'identifiant que vous voulez.

Les langues d'assemblage ont la destination dans l'opcode de gauche. Les langues de niveau supérieur ont tendance à suivre les conventions des langues précédentes.

Lorsque vous voyez =(ou :=pour les dialectes pascal), vous pouvez les prononcer ainsi is assigned the value, alors la nature de gauche à droite aura un sens (car nous lisons également de gauche à droite dans la plupart des langues). Comme les langages de programmation étaient principalement développés par des gens qui lisaient de gauche à droite, les conventions restaient en place.

C'est un type de dépendance au chemin . Je suppose que si la programmation informatique a été inventée par des personnes parlant l'hébreu ou l'arabe (ou une autre langue de droite à gauche), je suppose que nous placerions la destination à droite.

Pour ce que ça vaut la peine, la plupart des déclarations contenues dans COBOL lire de gauche à droite, de sorte que les deux opérandes ont été nommés en premier lieu , et la destination dernière, comme: multiply salary by rate giving tax.

Cependant, je ne suggérerai pas à votre élève de préférer COBOL, de peur que je ne sois (à juste titre) accusé de faire un commentaire aussi bas, grossier et sans goût! :-)

elle a dit que la gauche à droite lui semblait plus naturelle, car c'est ainsi que la plupart d'entre nous lisons les langues naturelles.

Je pense que c'est une erreur. D'une part, vous pouvez dire "attribuer 10 à x" ou "déplacer 10 à x". D'autre part, vous pouvez dire "régler x sur 10" ou "x devient 10".

En d'autres termes, selon votre choix de verbe, la variable assignée à peut être ou ne pas être le sujet, et peut être ou ne pas être à gauche. Donc, "ce qui est naturel" dépend entièrement de votre choix habituel de libellé pour représenter une cession.

En pseudo-code, l'opérateur d'affectation est très souvent écrit à droite. Par exemple

2*sqrt(x)/(3+y) -> z

Dans les calculatrices Casio, même dans les variantes non programmables, la variable d’affectation est également affichée à droite

A+2B → C

En Forth, la variable est également à droite

expression variable !

En x86, la syntaxe d'Intel a la destination à gauche, mais la syntaxe GAS inverse l'ordre, ce qui crée de la confusion chez de nombreuses personnes, en particulier pour les instructions relatives à l'ordre des paramètres telles que la soustraction ou les comparaisons. Ces instructions sont les mêmes dans 2 dialectes différents

mov rax, rbx    ; Intel syntax
movq %rbx, %rax ; GAS syntax

Ils déplacent tous les deux la valeur de rbx vers rax. Je ne connais aucune autre langue d'assemblage que je connaisse écrivant la destination à droite, comme GAS.

Certaines plates-formes mettent l'expression à gauche et la variable à droite:

MOVE expression TO variable      COBOL
expression → variable            TI-BASIC, Casio BASIC
expression -> variable           BETA, R
put expression into variable     LiveCode

https://en.wikipedia.org/wiki/Assignment_%28computer_science%29#Notation

La plupart des langues attribuent la valeur à gauche, l'une des raisons étant qu'il est facile d'aligner les opérateurs, de lire et de reconnaître la variable plus facilement, car les positions des opérateurs d'assignation et des variables ne varieront pas énormément dans les lignes et sont plus faciles à lire. "que la variable soit une valeur".

Cependant, certaines personnes préfèrent dire "déplacer la valeur x vers y" et écrire la variable à droite.

Je pense que cela suit une façon logique de penser.
Il doit d'abord y avoir une boîte (variable), puis un objet (valeur) à l'intérieur.
Vous ne mettez pas l'objet en l'air et ne placez pas ensuite une boîte autour.