Почему оператор присваивания присваивается левой стороне?

Я начала преподавать программирование подруге совсем недавно (мы используем Python), и когда мы начали обсуждать создание переменных и оператор присваивания, она спросила, почему значение справа присваивается имени слева, а не наоборот ,

Я не слишком много думал об этом раньше, потому что это казалось мне естественным, но она сказала, что слева направо кажется более естественным для нее, поскольку именно так большинство из нас читает естественные языки.

Я подумал об этом и пришел к выводу, что он значительно облегчает чтение кода, поскольку назначенные ему имена (которые программисту потребуется повторно использовать) легко видны и выровнены по левому краю.

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

В отличие от:

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

# What were the names again...?

Теперь мне интересно, есть ли другие причины для этого стандарта. Есть ли за этим история? Или есть какая-то техническая причина, почему это хороший вариант (я не знаю много о компиляторах)? И есть ли языки программирования, которые назначают на правую сторону?

То же самое @paxdiablo. Ранние языки программирования были написаны математиками - фактически, все они были. В математике, по ее собственному принципу - чтение слева направо - это имеет смысл в том, как это работает.

х = 2у - 4.

В математике вы бы сказали так: пусть х будет равен 2y -4.

Кроме того, даже в алгебре вы делаете это. Когда вы решаете уравнение для переменной, вы изолируете переменную, для которой вы решаете, слева. то есть y = mx + b;

Кроме того, как только целое семейство языков, например семейство C, имеет определенный синтаксис, его изменение обходится дороже.

BASICОдин из первых компьютерных языков имел «правильную» форму:

10 LET AREA = HEIGHT * WIDTH

который соответствует математическому мышлению при указании переменной, например «Пусть H будет высотой объекта».

COBOLбыло также похоже на его COMPUTEзаявление. Как и в случае со многими другими способами, это могло быть просто произвольное решение, которое было перенесено на многие языки.

На самом деле, есть язык программирования, который присваивается правой стороне: TI-BASIC ! Не только это, но он также не использует '=' в качестве оператора присваивания, а скорее использует стрелку, известную как оператор "STO".

Примеры:

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

В приведенном выше примере объявляются три переменные и им присваиваются значения. A будет 5, B будет 8, а C будет -3. Первое объявление / присвоение можно прочитать как «сохранить 5 как A».

Что касается того, почему TI-BASIC использует такую ​​систему для назначения, я объясняю это тем, что это язык программирования для калькулятора. Оператор «STO» в калькуляторах TI чаще всего использовался в обычных операциях калькулятора после вычисления числа. Если бы это был номер, который пользователь хотел запомнить, он нажал бы кнопку «STO», и caclulator запросит у них имя (автоматически задействует альфа-блокировку, чтобы нажатия клавиш производили буквы вместо цифр):

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

и пользователь мог бы назвать переменную как угодно. Необходимость включить альфа-блокировку, ввести имя, затем нажать «STO», и нажатие клавиши «Ans» было бы слишком громоздким для обычных операций. Поскольку все функции калькулятора доступны в TI-BASIC, никакие другие операторы присваивания не были добавлены, поскольку «STO» выполнял ту же задачу, хотя и в обратном направлении по сравнению с большинством других языков.

(Анекдот: TI-BASIC был одним из первых языков, которые я выучил, поэтому, когда я впервые изучал Java в колледже, я чувствовал, что назначение на ЛЕВОЙ было необычным и «задом наперед»!)

Эвристика 1: Когда вы сталкиваетесь с несколькими возможными способами сделать что-то во время разработки языка, выберите наиболее распространенный, наиболее интуитивный, иначе вы получите Perl +.

Теперь, как это более естественно (по крайней мере, для говорящего по-английски)? Давайте посмотрим, как мы пишем / говорим по-английски:

Стивену сейчас 10 лет (в отличие от 10 лет Стивену сейчас). Я вешу более 190 фунтов (в отличие от более 190 фунтов, которые я вешу).

В коде:

steven = 10
i > 190

Следующее также звучит более естественно:

«Если Мэри 18 лет, она может иметь конфету». «Если я моложе 21 года, то я попрошу у моего брата текилу».

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

чем:

«Если 18 лет, то Мария…» «Если 21 больше моего возраста ...»

Теперь код:

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

Обратите внимание, что это не естественно ни для программистов, ни для носителей английского языка. Предложения звучат как йода-говорящий, а код по прозвищу йода-условия. Это может быть полезно в C ++, но я уверен, что большинство людей с этим согласятся: если бы компилятор мог сделать тяжелую работу и облегчить потребность в yoda-условиях, жизнь была бы немного проще.

Конечно, можно привыкнуть ко всему. Например, число 81 записывается как:

Восемьдесят один (английский) Восемьдесят один и один (испанский) Один и восемьдесят (немецкий).

Наконец, есть 4! 24 правильных способа сказать «зеленое яблоко лежит на столе» на русском языке - порядок (почти) не имеет значения, за исключением того, что «on» должно сочетаться с «table». Так что, если вы являетесь носителем русского языка (например), то вам может быть все равно, пишете ли вы один a = 10или 10 = aпотому, что оба кажутся одинаково естественными.

В то время как лингвистика - захватывающий предмет, я никогда официально не изучал это и не знаю так много языков. Надеюсь, я предоставил достаточно контрпримеров.

Это началось с Фортрана в 1950-х годах. Где FORTRAN был аббревиатурой от FORmula TRANslation - речь идет о простых алгебраических уравнениях, которые по соглашению всегда назначаются слева.

С другой стороны, его почти современный COBOL должен был быть похожим на английский и иметь право (в основном!).

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

Ну, как указал @ diceguyd30, есть обе записи.

• <Identifier> = <Value>означает «пусть идентификатор будет значением ». Или расширить это: Определить (или переопределить) переменную Identifier to Value .
• <Value> -> <Identifier>означает «сохранить значение для идентификатора ». Или расширить это: Поместите Значение в место, обозначенное Идентификатором .

Конечно, вообще говоря, Идентификатор может фактически быть любым L-значением.

Первый подход учитывает абстрактную концепцию переменных, а второй - больше о фактическом хранении.

Обратите внимание, что первый подход также распространен в языках, которые не имеют назначений. Также обратите внимание, что определение и назначение переменной относительно близки по <Type> <Identifier> = <Value>сравнению с <Identifier> = <Value>.

Как уже упоминалось, все ранние компьютерные языки работали очень хорошо. Например, Фортран, появившийся за много лет до Бейсика.

На самом деле имеет смысл иметь присвоенную переменную слева от выражения присваивания. В некоторых языках у вас может быть несколько разных перегруженных подпрограмм с тем же именем, возвращающих разные типы результатов. Позволяя компилятору сначала увидеть тип назначенной переменной, он знает, какую перегруженную подпрограмму вызывать или какую неявную приведение генерировать при преобразовании из (например) целого числа в число с плавающей точкой. Это немного упрощенное объяснение, но, надеюсь, вы поняли идею.

Это может быть остатком ранних алгоритмов разбора. Помните, что разбор LR был изобретен только в 1965 году, и вполне может быть, что у парсеров LL были проблемы (в пределах временных и пространственных ограничений машин в то время), которые шли наоборот. Рассмотреть возможность:

identifier = function();
function();

Два явно устранены неоднозначностью от второго жетона. С другой стороны,

function() = identifier;
function();

Не весело. Это ухудшается, когда вы начинаете вкладывать выражения присваивания.

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

Конечно, более легкое устранение неоднозначности для машин также означает более простое устранение неоднозначности для людей. Другой простой пример - поиск инициализации любого заданного идентификатора.

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

Легко, просто посмотрите на левую сторону. Правая сторона, с другой стороны

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

Особенно, когда вы не можете grepперфорировать карты, гораздо сложнее найти нужный идентификатор.

Языки ассемблера имеют место назначения как часть левого кода операции. Языки более высокого уровня, как правило, следовали соглашениям языков предшественников.

Когда вы видите =(или :=для диалектов Pascalish), вы можете произносить их как is assigned the value, тогда смысл слева направо будет иметь смысл (потому что мы также читаем слева направо на большинстве языков). Поскольку языки программирования преимущественно разрабатывались людьми, читающими слева направо, соглашения придерживались.

Это тип зависимости от пути . Я полагаю, что если бы компьютерное программирование было изобретено людьми, которые говорили на иврите или арабском (или каком-либо другом языке справа налево), то я подозреваю, что мы бы указали пункт назначения справа.

Для чего это стоит, большинство операторов , в COBOL читать слева направо, так что оба операнда были названы первый и последний пункт назначения, как: multiply salary by rate giving tax.

Я не буду, однако, предполагать, что ваш ученик может предпочесть КОБОЛ, потому что боится, что меня (совершенно справедливо) пометят за такой низкий, неуклюжий, безвкусный комментарий! :-)

она сказала, что слева направо кажется более естественным для нее, поскольку именно так большинство из нас читает естественные языки.

Я думаю, что это ошибка. С одной стороны, вы можете сказать «назначить 10 на х» или «переместить 10 на х». С другой стороны, вы можете сказать «установить х в 10» или «х становится 10».

Другими словами, в зависимости от вашего выбора глагола, назначаемая переменная может быть или не быть субъектом, а может и не быть слева. Таким образом, «то, что естественно», полностью зависит от вашего привычного выбора формулировки для представления задания.

В псевдокоде оператор присваивания очень часто пишется справа. Например

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

В калькуляторах Casio, даже непрограммируемых вариантах, переменная присваивания также отображается справа

A+2B → C

В Forth переменная тоже справа

expression variable !

В x86 синтаксис Intel имеет место назначения слева, но синтаксис GAS меняет порядок в обратном порядке, что вводит в заблуждение многих людей, особенно в отношении инструкций, касающихся порядка параметров, таких как вычитание или сравнение. Эти инструкции одинаковы на 2 разных диалектах

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

Они оба перемещают значение в rbx в rax. Не знаю других языков ассемблера, напишите пункт назначения справа, как ГАЗ.

Некоторые платформы помещают выражение слева и переменную справа:

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

Большинство языков присваивают значение слева, что является одной из причин, по которой легко выравнивать операторы, легче читать и распознавать переменную, поскольку операторы присваивания и положения переменных не будут сильно различаться в строках, и их легче читать как msgstr "пусть переменная будет некоторым значением".

Однако некоторые люди предпочитают говорить «переместить значение x в y» и написать переменную справа.

Я думаю, что это следует логическому мышлению.
Сначала должен быть блок (переменная), затем вы помещаете в него объект (значение).
Вы не помещаете объект в воздух и затем помещаете коробку вокруг этого.