Comments 39
Это как в программировании, в команде присвоения указать a = 5 — можно.
А указать, 5 = a — в общем-то, бессмысленно.
Это всё зависит от языка. Например, в tcl я могу и переменной а присвоить 5 и переменной 5 присвоить a:
% set a 5
5
% set 5 a
a
%
И всё будет нормально. И это позволяет красиво программировать многие вещи.
#define TRUE FALSE //Happy debugging suckers
Я с вами отчасти согласен. Некоторые вещи TCL позволяет сделать очень изящно. Но! За такие изящества обычно сильно бьют в командной разработке :)
Мне TCL своей простотой и идеей очень понравился. Как язык для самовыражения и получения удовольствия он хорош. Но писать что-то коммерческое или командой я бы не стал. Тем не менее это мой любимый язык.
Может быть сложно аналогию разобрать, или я плохо описал её, или сама аналогия не стоящая, но статья в минусе, а в комментарии обсуждения того, что число и буквенное значение можно приравнять не обращая внимание на направление равенства. Ну, в целом, в математике так и есть. Но тема различия сторон в присваивании и правосторонних ссылок это, наверное, развитие языка, а не какие-то ограничения возможностей.
А то что блюдце это аналог места в памяти не написано и может ускользнуть при чтении.
На мой взгляд, более приемлемым аналогом здесь был бы спичечный коробок:
Представь себе кучу пронумерованных/подписанных спичечных коробков, в каждом из которых лежит какое-то количество спичек. Коробок со спичками – это и есть ячейка. Адрес ячейки – это номер коробка или его название. Теперь предположим, что надо узнать, сколько всего спичек хранится в пятом и десятом коробках вместе, т.е. выполнить операцию сложения, и такое же количество спичек положить в коробок с номером 15. Заглядываем в коробок №5 и запоминаем сколько в нём спичек, затем аналогичным образом поступаем с коробком №10, складываем запомненные значения. Это и есть то количество спичек, которое нужно положить в коробок №15. ЭВМ делает тоже самое, только не с коробками, а с ячейками памяти
разницы между блюдцем и коробком особо-то и нет.
Конечно нет, за исключением того, что спичечный коробок, в котором лежала спичка, невозможно засунуть в спичку, которая лежит в этом коробке, а вот блюдце, на котором стояла чашка. можно легко поставить на чашку. под которой оно только что лежало. Мы же говорим про аналогии...
Вопрос здесь не в различии сторон присваивания, а в том, что численный литерал в большинстве языков всегда имеет значением самого себя.
Это предельно ясно в синтаксисе Лиспа и производных от него языков. 5 – это то же самое, что '5, а вот a – это в общем случае не то же самое, что 'a.
А оператор присваивания – это просто частный случай. Он действительно так устроен в языке Си, что у него правая и левая части вычисляются по разным правилам, но дело не в нём.
И всё будет нормально. И это позволяет красиво программировать многие вещи.
Какие например?
Например? Вам необходимо хранить информацию и нескольких процессах или свойствах графических объектов. Создаете для каждого такого объекта массив или список, где идентификатором массива/списка выступает id процесса или графического объекта на холсте.
Непонятно. Там был комментарий saipr
Например, в tcl я могу и переменной а присвоить 5 и переменной 5 присвоить a:
Меня очень удивило, что значит "переменной 5 присвоить a", что это вообще может значить? Что такое "переменная 5", если это литеральная константа? Что произойдет в программе, если язык программирования все-же позволит осуществить такое присваивание? Чему будет равна константа 5 после этого?
Просто выполните приведённый пример и всё увидите. Прочитайте описание tcl.
Я зык программирования tcl прекрасно понимает где литерная консанта 5, а где переменная с идентификатором 5.
В Tcl то, где переменная, а где - литерал, зависит от контекста:
# Literal
set Hello 5
puts $Hello
# Variable
set 5 Hello
puts $5Никаких неоднозначностей не возникает.
Имя переменной может быть и цифрой? Непривычное.
Даже зная что такое переменные и rvalue/lvalue, описанный мир возникающих ниоткуда волшебных чашек я понять не осилил, даже прочитав несколько раз. Ни в отрыве от программирования, ни по аналогии.
Я даже не смог понять, что именно (и кому) объясняет автор – способ вычисления значения выражения или систему статической типизации.
Статья является примером, как можно предельно запутать несложный вопрос.
Да. Плохая аналогия подобна дверце с котёнком.
возникающих ниоткуда волшебных чашек
В программе постоянно из одних значений получаются новые, а при передаче в функцию по значению происходит копирование. Необычность, если она и есть, заключается не в данном мной описании, а в том, что в программах именно так всё и происходит.
Возможно, вам из-за того что простые вещи кажутся очевидными, не понять, как людям только осваивающим абстрактную область сложно приспособить свою бытовую интуицию. Но уж говорить что всё усложнено — это уже явная мнительность.
Но в целом, очень благодарю за комментарий! Я даже не предполагал, что такие мнительные люди считают себя вправе что-то оценивать.
Так у вас чай копируется или чашки с чаем? Я уже этого не смог понять из текста.
А оценивать я уж точно вправе, отучившись в аспирантуре по программированию :)
А в аналогии чай и чашка чая одно потому что чай без чашки в воздухе не удерживаться. Вы этого не поняли проучившись в аспирантуре. Ну так и какие выводы?
Хотя, если без усмешек, в первой же части видно что чашка копируется целиком. Разве нет?
Если вы считаете целесообразным надо мной насмехаться, то делайте это, сколько сочтёте нужным, я не обижусь.
Аспирантура – это именно то место, где присваивается право преподавания теоретических дисциплин в высшем учебном заведении и, соответственно, оценивания знаний по вузовским дисциплинам, к которым относятся теоретические вопросы программирования. Это вам для справки.
А если для вас чай и чашка чая – одно и то же, то у вас очень неконкретное мышление, которое в данном случае мешает построить правильную аналогию в таком формальном вопросе.
Если значение – это сам чай, то откуда при копировании значений у вас возникают чашки на блюдцах? Если же значение – это чашка с чаем, то что в ваших аналогиях означает упомянутая далее операция переливания?
Все эти мысли мне отчасти напомнили рассуждения пелевинского Чапаева о форме самогона, но программирования в этом мало.
Давайте вырулим разговор на что-нибудь полезное? Вряд мне вам получится указать на ваши заблуждение. Ну вот, что вы себя зря апломбировали — это уже и так понятно, но разве вы согласитесь?
Я могу лишь согласиться что в статье это действительно не формальное и не учебное объяснение. А вот то что не полезное, или вредное — это уже просто ваше «верьте мне я доктор». Хотя уровень аргументации уже очевиден.
Вам выше правильно указали более подходящую аналогию с коробками спичек. Как минимум, по четырём причинам. Спички помещаются внутрь коробка, спички дискретны, ценность одинаковых спичек безусловно заключается в их количестве, и отсчитать в другой коробок равное количество спичек для копирования можно, не прибегая к волшебству.
Касательно аспирантуры. Вы упомянули впрос, ВПРАВЕ ли я что-то оценивать. ПРАВО оценивать (в формальном, юридическом смысле) даёт именно аспирантура, о чём я вам и ответил. А в гражданском смысле право оценивать есть у каждого. Ваше уважение и внимание к моему мнению – другое дело, ваше личное, меня оно не очень касается.
Полезность объяснять свойство вложения через невозможность обратного вложения оставляет выбор не за тем кто так делает. Здесь свои минусы. Тоже объяснение через себя.
Волшебство в статье заключается только в том что суммарный объем чая не сохраняется и блюдца вначале самостоятельно собираются с собой — это не на столько переполняет воображение как вы хотите показать.
А в задачу статьи входило ещё и объяснить понятие числа?
ценность одинаковых спичек безусловно заключается в их количестве
Ну вот это — разе достоинство в контексте статьи?
Конечно, вы же значение переменной оцениваете исключительно по записанному по её адресу двоичному числу. У одного человека 20 спичек и у другого 20 спичек той же марки.
А чай если переливать из чашки в чашку, да ещё когда по пути разные люди прихлёбывают и его пробуют – он заведомо изменит свои свойства.
Может вы просто с непривычки так среагировали? К своим-то аналогиям привыкли.
Я сразу написал, что вообще не смог понять построенную Вами аналогию и объясняемый ею предмет. Поэтому вопрос тут не в привычке, тем более что о спичках я точно так же впервые прочёл сегодня на этой странице.
С тем, что переменные содержат вкус или цвет, я не согласен. Переменные содержат свои значения, то есть двоичные числа в памяти. А уже эти значения могут использоваться архитектором программы для представления цвета, но это совершенно другой вопрос, не касающийся семантики языка программирования.
Поэтому благородные мужи древности сказали бы, что не надо уподоблять такую низкую вещь, как устройство компьютера, такой высокой вещи, как чайная церемония :)
Честно говоря, вопрос, который Вы вскользь поднимаете в конце текста, касательно отличия семантики копирования от семантики перемещения, вообще затруднительно объяснить бытовыми аналогиями, потому что это в чистом виде вопрос вычислительной эффективности программного кода. Никакая семантика перемещения вообще не нужна, если абстрагироваться от затрат на память и на работу сборщика мусора.
Я думаю, мне кажется, автор вообще не хотел ничего объяснять - он просто попытался акцентировать внимание на том, что формально перемещение чего-то в рамках некоторой логики, на самом деле, буквально физически - им не является. Перемещение является копированием.
И что это в рамках физического мира - довольно необычно. А в рамках того, что придумал человек - выглядит как норма. Но не потому что это действительно норма.
Он попытался нарисовать гипотетическую повседневную ситуацию, подобную, в которой такое расхождение - выглядело бы странно и заметно.
Может он рассчитывал, что кто-то задаст себе вопрос, чтото в духе: "Хм, и правда - почему так? Почему я так по разному принимаю похожие процессы?"
А может вообще пытался поймать за хвост разницу своего собственного отношения к типологически идентичным событиям. Мне так кажется.
Я бы сказал даже больше — лично мне конкретно такого объяснения и не хватало в своё время. Все объяснения были основаны не на аналогиях а на то что кто-то что-то придумал и его объяснениям надо просто верить.
Я бы хотел пояснений, почему она плохая.
В основном потому что она ничего не объясняет, а только запутывает. Гость, который уходит и забирает с собой чашки - это что за персонаж, например? Сборщик мусора? Тогда это совсем не отсюда. Куда он уходит, что он там делает с чашками, и что происходит с чаем?
Пример со спичечными коробками лучше.
После пары+ банок пива появились вопросы: зачем гостям ходить со своими блюдцами, если частенько чайник выдаёт новые блюдца с пометкой. Весь смысл наличия своих блюдец (как обязательного условия прихода в гости) теряется. Если же чайник работает без своих блюдец, то как под чайником могут получаться чашки с новым чаем, которая и не в руках и не на скатерти+блюдце?
Если смешивание двух чаёв большого объёма требует большего времени, то почему копирование (что можно представить как переливание из чайника из одной чашки (вторая пустая (интересно, такие могут существовать?))) не даёт такого эффекта?
Гость (по лору) может угостить хозяйку своим чаем. Как он появился у гостя? Принёс с собой? Тогда зачем таскать блюдца, если можно принести с собой чашки с чаем?
Может ли гость дополнить принесённую с собой чашку чаем из чайника и унести на своём блюдце на другое чаепитие и там отдать хозяйке (только чашку)?
Получается, чтобы на блюдце что-то ставить, нужно иметь блюдце.
Второй вопрос. Время занимает копирование оно же переливание, а сколько чайник — это уже от чайника зависит. Может и мгновенно. Здесь чайник это аналогия встроенных функций. Всего их разнообразия.
Третий вопрос. Ну да, гость может приходить со своим чаем. Начальные значения для переменных в функциях — могут же быть. Чашки с чаем принести с собой можно, но на стол их без блюдец не поставишь. Хотя, наверное, можно держать в кармане и копировать при надобности. Как константы.
Четвёртый. Может. Только, это будет функция, которая не просто вызывается несколько раз, но ещё и хранит между вызовами состояние. Такое существует, но это не обычная функция.
Чаепитие из rvalue