Рецензия на книги А. В. Столярова

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

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

Наглядно и запоминабельно)

Я, конечно, читал Столярова достаточно давно, но даже я помню, что понятие побочные эффекта вводилось для выражений.

Но поскольку никто не способен открыть книгу, придётся это сделать мне.

Определение из параграфа 2.3.6 (издание 2.9, том 1):

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

Напоминание в параграфе 4.8.3 (издание 2, том 2):

Напомним, что о побочных эффектах говорят, когда при вычислении выражения произошло что-то ещё, кроме собственно создания результата.

Утрирование аргументом не является.

Не спорю

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

согласно этому определению, никакой вызов функции не может быть чистым, так как изменяется состояние стека

Если после вызова функции у Вас изменилось состояние стека, то это беда.

Если после вызова функции у Вас изменилось состояние стека

конечно изменилось, а куда вы собираетесь результат функции записывать? Да и то сказать, у автора нет слова «после» в определении

так и так и чпок - утекает вся память или валится система. Наглядно и запоминабельно)

Самого Андрея Викторовича программирование в 16-разрядной Windows многому наглядно научило. Хочешь одним глазком взглянуть на байтик сразу после массива, и…

https://upload.wikimedia.org/wikipedia/commons/2/2a/Unrecoverable_Application_Error.png

ISO/IEC 2382:2015(en) Information technology — Vocabulary

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

Сравни с определением из стандарта:

2122490

side effect

any indirect consequence caused by the execution of an expression, statement, or subprogram

Note 1 to entry: Side effects may be intended, for example, to change the data value of a parameter passed by a function.

Note 2 to entry: side effect : term and definition standardized by ISO/IEC [ISO/IEC 2382-15:1999].

Note 3 to entry: 15.08.03 (2382)

Всего одно слово «indirect», и без него определение полностью теряет смысл.

/* старательно делает вид что хоть что-то понял */

😊

Стандарт писали мерзкие комитетчики!!!111

Побочка это неожиданный в общем фефект ,

Оставление результата на стеке(Али при ином Аби в наборе регистров) ожидаемо

И таки да ожидаемая неожиданасть и обработка ея и отличает пользователей от скруполезных прогерлов

Контекст учебника иной чем стандарта в котором часто приходится либо повторять в каком окружении клауза либо наворачивать тезаурус без которого читать могут не только лишь все

Почему только неожиданный? Может быть и ожиданным эффектом, зависит от квалификации программиста.

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

Если хочется математической строгости, то для этого есть понятие чистой функции, но это уже совсем другая область знаний, computer science и прикладное программирование связаны весьма слабо.

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

По поводу побочных эффектов - я когда-то заводил тред, т.к. не нашел внятного определения в книге: Побочные эффекты функций

И там на 4-х страницах так и не пришли к консенсусу что такое побочный эффект. А в конце набежал сам Croco и еще больше всех запутал.

Математически строгое определение функции без побочных эффектов это определение чистой функции, соотв. побочный эффект это те изменения, без которых функция будет чистой.

Для языка С/С++, Паскаля и пр., его нужно адаптировать.

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

Дальше надо определиться с терминами что такое программа из чего она состоит, т.е. дойти до определённого уровня детализации и сказать, что дальше мы не смотрим. Скажем, если мы ограничимся рассмотрением программы только как последовательности инструкций + множество переменных, то мы выкинем из рассмотрения такие вещи, как стек вызова функций, внешний мир (системный вызов, вывод в консоль и пр.), и пр.

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

Для ООП его, возможно, стоит расширить, до всех родителей классов, т.е. считать, что в явном виде есть переменные, их классы, все предки класса… Хотя, я бы этого не делал. Чем проще определение, тем лучше. Тут лучше говорить об ожидаемых побочных эффектах и о неожидаемых, ведь если мы создаем новый объект, то, наверное, мы ожидаем вызовы конструкторов…

Уже по той твоей теме я понял, что ты не способен читать.

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

Итак, побочные эффекты бывают только у арифметических выражений.

Ещё раз: побочные эффекты бывают только у арифметических выражений.

Наличие или отсутствие побочных эффектов в языке является частью семантики языка.

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

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

Про другие языки обсуждать с тобой что-то рано, если ты даже это понять не способен.

О, ещё одно определение. Скоро коллекцию соберу.

Рецензию на 1500 страниц невозможно написать без анализа личности автора и контекста создания произведения.

Несогласен cat /dev/urandom >/dev/brain способен творить чудеса.

Трёхтомник Столярова позиционируется как введение в профессию, т.е. набор текстов, изучив которые, читатель обретёт навыки, необходимые для получения рабочего места.

А это где такое написано?

Собственно Вам три года назад уже ответили, что Вас не устраивает?

Я честно попытался понять что тут сказано, но не понял.

Итак, побочные эффекты бывают только у арифметических выражений.

Ок, рассматриваем только арифметические выражения.

Наличие или отсутствие побочных эффектов в языке является частью семантики языка.

Наверное, это утверждение верное, но я не знаю живого ЯП, у которого семантика не позволяла бы создавать побочные эффекты с т.з. общего смысла, это является частью семантики языка и, кмк, частью архитектуры вычислителя (это уточнение, имхо, необходимо, если речь идет о прикладном программировании, а не о computer science).

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

Вот тут я уже ничего не понял, «add AX, BX» это вычисляемое в рантайме выражение? Если нет, то нужно определение выражения рантайма. Если да, то установление флага переполнения это сторонний эффект или нет? Если нет, то почему? А попытка записать байт в 0 адрес и последующий краш это сторонний эффект или нет?

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

А ты уверен, что синтаксис современного Паскаля не позволяет вызвать процедуру внутри выражения?

А inc(x) это арифметическое выражение или нет? Какое определение арифметического выражения дается в домене книги?

А inc(x) это арифметическое выражение или нет?

Это процедура. А вот ++x или x++ это выражения.

А в чем различие?

А если эта процедура приведет к переполнению типа и установлению соотв. флага – это side effect или нет?

Мозг даже пятнадцатилетнего указатели за 45 минут урока туго воспринимает.

Да бросьте. Указатели объясняются за 5 минут. Есть бутылка вотка, на ней наклейка вотка. Теперь переходим к указателям. Берем ещё одну этикетку «вотка» на которой пишем «вотка в холодильнике» и клеим эту этикетку например на дверцу бара. Вот вторая этикетка является указателем.
Расширяем тему указателей. Кто-то достал бутылку из холодильника, выпил, а бутылку выбросил. Но! этикетка на дверце бара никуда не делась, теперь она указывает на несуществующую вотка.
Сложение. Для кровавой мэри недостаточно взять две бумажки с надписью вотка и сок. Надо сходить за вотка и соком в места указанные на этих бумажках.

А в чем различие?

Так нельзя y:= inc(x), а так можно y = x++

А а паскале есть ++ ? И опять же вопрос был в том, считаем ли установление флага переполнения сторонним эффектом или нет? Если нет, то почему (в рамках определения)?

считаем ли установление флага переполнения сторонним эффектом или нет?

Нет. Потому что он ни на что не влияет. И в рамках ЯВУ никакого флага переполнения не существует.

А а паскале есть ++ ?

В FreePascal может быть и есть.

Да бросьте. Указатели объясняются за 5 минут.

Объясняется за 5 минут, а прививается неделями, порой на это требуется год.

Я вот недавно попреподавал в Китае ихним студентам, не в лучшем университете, и надо сказать что несколько пересмотрел свои взгляды на методы составления занятий. Вот сколько раз нужно человеку совершить ошибку и объяснить ему в чем она, чтобы он ее не делал? Речь идет об элементарной ошибке, типа поставить точку с запятой вот тут:

for(…);

{ … }

так вот удивительно, что и 8 раз повторений не приводят к 99% эффекту, все равно ставят и тупят в отладке… Хотя казалось бы… Да и ребята в целом производили впечатление адекватных…

Нет. Потому что он ни на что не влияет.

Но в вашем определении сайд-эффекта нет ничего про «влияние»

Нет. Потому что он ни на что не влияет. И в рамках ЯВУ никакого флага переполнения не существует.

Ну это простой пример, можно так же в процедуре вызвать сегфолт, это сторонний эффект или нет?

А что такое ЯВУ? Я русскую терминологию не особо знаю. Собственно, я и не специализировался при получении высшего образования в программировании…

Нет никакого сайд эффекта в этом случае. В рамках ЯВУ флага переполнения просто не существует.

Ну это простой пример, можно так же в процедуре вызвать сегфолт, это сторонний эффект или нет?

Конечно. Но это уже не нормальное исполнение программы.

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

Я?

Нет, не вы, я ошибся.

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

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

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

Ассемблер здесь не причем. Он, собственно, императивнее некуда.

Вот к чему этот комментарий? Я действительно хотел бы услышать ответы на вполне конкретные вопросы, которые я задал. Мне это интересно, в т.ч. и с проф. т.з.

К тому о чем написал, причем здесь ассемблер? Можно еще вспомнить микрокод и кеш. О побочном эффекте говорят, обычно, когда речь идет о вычислении выражений. В ассемблере нет никаких выражений вообще.

Вот есть такая веселая функция random(), она не изменяет никакого состояния, но в любом языке считается сайд-эффектом. Почему? Потому что портит чистоту функции. Чистая функция, это функция, вызов которой при известных аргументах можно закешировать. Вот и всё определение сайд-эффекта. Если вызов функции нельзя заменить известным её результатом, значит в ней есть эффект. За сим срач можно закрывать.

Что такое выражение? (про ассемблер ты сам заговорил)

add AX, BX # это выражение? Я, как математик, считаю это выражением.

О побочном эффекте говорят, обычно, когда речь идет о вычислении выражений

Судя по стандарту, обычно про побочные эффекты говорят, когда речь идет про функции, выражения, определения (statements).

Вот есть такая веселая функция random(), она не изменяет никакого состояния, но в любом языке считается сайд-эффектом. Почему?

Конечно же меняет, обычно это глобальная переменная называемая randseed или что-то вроде этого.

Это команда сложения содержимого двух регистров.

И?

Нет, вы можете спокойненько читать из dev/uramdom или мерять температуру процессора, это иммутабельные операции

Более того, книги не содержат описания базовых инструментов администрирования.

Поперхнулся. В названии книг слово администрирование вроде как отсутствует.

То есть, изучив все эти талмуды, студент не сможет претендовать даже на рабочее место администратора Linux

А ещё он не сможет класть печку, вышивать крестиком, дрессировать тигров... и во всем этом виноват Столяров.

Че-то ты не быстро тред читаешь, до треша пока не дошел еще.

Это ничего не меняет это просто чтение переменной, значение которой меняется извне. Побочный эффект в чистом виде.

Может дело не в бабине ребятах?

Может, но когда ты учишь, у тебя есть некоторые предварительные предположения об уровне студентов. Я, конечно, адаптируюсь к ситуации, но это реально было удивительно. По моему ощущению это были ребята примерно на уровне 8-9 класса. А это совсем другой уровень, я вот даже на первых курсах вынужден преподавать совсем иначе, чем на 3-4м (где я обычно и преподаю). А тут фактически, по уровню развития, школьники, т.е. аудитория с которой я никогда серьезно дела не имел…

Я не об уровне ребят, а о вас. Это вы так излагаете, что у них возникают такие вопросы. Разная культура, разный менталитет, разные методики преподавания... много чего разного. А в вашем случае всё это усугубляется тем, что вы преподаете в их естественной среде.