Инвариант в программировании

[@lalivirtei]

Очень спокойно и уютно стало во время просмотра. Конец тяжёлой недели и от кода уже воротит, но сейчас, на середине видео, снова захотелось работать. Спасибо. Цветовая гамма видео, отлично подобрана. Особенно контраст ламп и рубашки. Приятно смотреть.

[@fazleev]

Слушаю перед сном, пока что ни разу не добрался и до середины - вырубает отменно )

[@S0ERDEVS]

Хоть какая-то польза от этих видосов

[@ruslanshikhaliev9341]

спим в учении Андрейка, не спим в бою (на проде)

[@ТимурСаляхов-е6е]

Как же не хватате хорошего такого курса лекций от этого товарища от начала и до..

[@prinimaushaya_storona]

Спасибо за контент! Думаю что часть комментаторов, которым это не понятно, не стоит того, чтобы терять ту часть, что это с удовольствием смотрит.

[@alfobarasovich55]

Один из самых ДУШЕВНЫХ каналов о программировании

[@resetand]

Как на счет видео про машину тьюринга?)

[@veeronten4886]

Спасибо за видосик. Очень хотелось бы посмотреть в твоём исполнении пример использования инвариантов, безотносительно слабой типизации.

[@НиколайРоговой-ф4х]

все тоже самое, только с проверкой что значение в теге >=0

[@phil2964]

спасибо за контент и отдельное что без политики

[@ИмяФамилия-э4ф7в]

Сам попросил, в Беларуси Лукашенку как раз проверяют на инвариант.

[@sergeyvoitenko8978]

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

[@MrJloa]

Оригинальное объяснение. Весьма хорошо вышло.

[@an2anSz]

Спасибо за труд!

[@nekosora6036]

Так для чего нужно каррирование то?

[@klmbk8187]

😂😂

[@isopp7744]

Когда я интересовался меня послали в исходники фреймворков и что то там про lodash, но живых примеров так и не привели.

[@viss23]

На собесах могут спросить, хех

[@ИапГоревич]

@@viss23 Ахахах

[@isopp7744]

@@viss23 И потом так - фуфуфу, ты не знаешь за каррирование, фуфуфу пративный... А ты такой, "извините я вам не подхожу, я привык работать в гетеросексуальных коллективах".

[@chu_ri5470]

Чуть дополню. 6:20 - важно заметить, что M' должны быть как можно меньше. То есть функция в 200+ строк в начале которой и в конце одни и те же переменные отображают разные множества это плохая практика. Её крайне сложно верифицировать. Хотя всегда можно ввести новые инварианты для доказательства соблюдения инвариантности вышестоящего блока, лучше делать это в локальных областях с новыми переменными. Что хорошее направление для рефакторинга и повод смотреть в сторону декларатива и чистых функций. + инвариант составляет тот кто верифицирует код и может быть задан любыми целесообразными логическими условиями. В том числе даже теми которые вы не можете легко проверить в коде.

[@RichardGraveman]

спасибо!

[@mikekushchenko5855]

Дед ты меня радуешь по пятницам

[@АлексейТитов-д9э]

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

[@Mike-hp3fh]

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

[@khodyrevds]

Как раз математическое определение предельно понятно, это я как математик говорю.

[@ievgenk.8991]

И что теперь?

[@AlexYaroshevich]

Лучше посмотрим непонятное определение на 19 минут)

[@АндрейРеш-г9в]

Спасибо.

[@ИгорьКабакин-ц7у]

Ну рычагом, можно не только повысить, но и ослабить усилие - нарастив скорость (ну или траекторию,путь) 🙂.

[@sputnyq]

Что за Boilerplate с пуговицами сверху?

[@suryaninov]

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

[@0xgur0xverflow59]

Го про конечные автоматы

[@andyvoice]

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

[@MIXEL3D3]

Спасибо мистер)

[@АндрейРеш-г9в]

Какая хорошая подача. Как это писать перед собой? Тоже спонсорский вопрос?

[@TheHandOfKwll]

Тройки Хоара, контрактное программирование, инварианты - почти синонимы?

[@xabikiqwe]

В MS Visual C++ когда объявляешь тип структуры и добавляешь внутрь метод, метод автоматом добавляется с подчёркиванием. Это связано с ответственностью?

[@АндрейРеш-г9в]

Скажите, можно узнать. Что Вы имели в виду у JS слабая типизация? Спасибо. Это же у Pithon?

[@СергейПресняков-о4р]

Не путайте динамическую типизацию и слабую. У JS динамическая слабая, у Python динамическая сильная. JS позволит сложить 1 и "1", Python сразу выбросит TypeError, потому как можно сложить число с числом и строку со строкой (конкатенация), но разные типы так применять нельзя. В языках с динамической типизацией тип переменной может меняться в процессе, например в одной строке мы можем сделать x = 1, а далее x = "Hello, world". В языках со статической типизацией, если мы определили переменную как int x = 1, то далее мы можем менять её значение, но не тип - эта переменная только под целые числа.

[@АндрейРеш-г9в]

@@СергейПресняков-о4р типизации как то смешаны. У Pithon и JS динамическая типизация. А другие о чем обьясняются. Сережа.

[@dann1kid]

короч, на питоне это "ассерт" для тестирования. Есть три подмодуля - входные данные, функция изменения, выходные данные. Есть вход на данные (что проверяется) и есть выход(тоже проверяются). Если данные ок, то функция работает крутится меняет считает. Если выход ок, то исключения не вызываются и данные допускаются для передачи. Пример: число фибонначи. 1) вход (чекаем тип данных) (ивариант типа данных) 2) функция делает вычисления. 3) сверяется с рядом фибонначи. (инвариант принадлежности)

[@dalerkhalilov9440]

Mozg 💪

[@chu_ri5470]

Мне больше нравится такой пример, без лишних абстракций: количествоПосчитанныхСтудентов = 0 for человекВАудитории in всеЛюдиВАудитории: ___if(этоСтудент(человекВАудитории)) ________количествоПосчитанныхСтудентов+=1 Здесь инвариант, это "переменная количествоПосчитанныхСтудентов всегда содержит количество посчитанных студентов".

[@iNemoden]

Инвариант это не unit-тестирование и не assert в python. Инвариант - это проверка консистентности модуля, а не правильности работы алгоритмов/валидации входных/выходных данных методов. Пример: метод может быть инвариантен, но для него можно определить ассерты входных/выходных данных и тогда это просто обычное юнит-тестирование.

[@dann1kid]

@@iNemoden А если консистенция проверяется таким тестированием на входные и выходные данные? Здесь тоже достигается инвариантность. Так или иначе это абстракция, а каким образом она достигнута - это удел инженерной мысли

[@iNemoden]

@@dann1kid конечно, это в принципе как любое многообразие. Если то же самое достигается иными методами у этих методов будут преимущества и недостатки и программист или команда может решить что именно использовать, но для того чтобы понимать что использовать нужно знать о разных подходах и их плюсах и минусах чтобы понять какие плюсы и минусы перевешивают. Я сам инварианты использовал в своей 13-летней практике по пальцам пересчитать сколько раз, но если бы я не знал что это, у меня бы не было возможности их применить. Я бы сказал что знание того что такое инвариант это как знание основных алгоритмов сортировки - очень редко нужно реализовать, но знать нужно обязательно потому что когда-нибудь может пригодиться.

[@kirillsviderski4739]

Очень сложное объяснение. Почему бы просто не показать пример с законом Ома, например?) Типо, нужно симулировать электрическую сеть. Тогда для каждого элемента должен соблюдаться инвариант. А значит, поля U, I, R надо спрятать под абстракцию правильно написанных сеттеров, что бы при изменении сохранялся инвариант

[@0imax]

Закон Ома знаю, программировать умею (и под железо, и под десктоп), но из объяснения ни хрена не понял :)

[@КириллЧе-я5ы]

К примеру, в контрактном программировании инвариант - это контракт

[@igordmitrow2815]

Так инкапсуляция это сокритие данных?

[@InSimpleWords_WebDev]

Инкапсуляция - это скорее больше адекватное моделирование сущности. "Вы в капсулу заключаете сущность". Например, берете страшилу из "страны ОЗ". Его модель - это соломенные опилки, костюм пугала, прихрамывающая походка. Если вы припишите ему сердце железного человека, или умение прыгать как тигр, или родителей главной героини - вы нарушите инкапсуляцию этого страшилы. Сокрытие данных - это вторичный вопрос инкапсуляции. Например, мозги лучше спрять в голову, а костюм пугала лучше оставить видным всему честному народу. Так что соединение данных и методов для их обработки в осмысленную единую сущность - это и называют инкапсуляцией.

[@vladkolesnik2274]

@@InSimpleWords_WebDev круто разложил

[@InSimpleWords_WebDev]

@@vladkolesnik2274 Спасибо.

[@lambdaway]

Инкапсуляция это когда тебя хотят накормить через ж* , а ты падаешь и кричишь, что у тебя для этого есть рот)

[@vovanchik_ru4208]

дык вот для чего придумали этот странный javascript.... В строготипизированном языке об инварианте практически не думаешь, т.к. некуда деться из подводной лодки. А в js конечно всё прекрасно, сладко аж засахариваешься, но только до тех пор пока не захочешь сделать всё правильно :) А когда ума набираешься и хочешь дальше программировать на js, то приходится контролировать инвариантность, ну или строго замарочиться typescript-ом :) Ну вот если бы не js, то когда бы я бы ещё узнал о инвариантах...? :)

[@ЕгорТвердохлеб-й2р]

у Вас кабель от микрофона перетянут)

[@AlexYaroshevich]

А каррирование здесь при чем?

[@НиколайРоговой-ф4х]

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

[@mojeimja]

JS как всегда 0+_k чтобы принудить к численному типу. 2+2=22

[@isopp7744]

Инвариант = in variant( внутри вариантов). Инвариант в программировании - техника, реализованная в виде оболочки, которая позволяет проверить, что "что-то" точно соответствует "чему-то". Так?

[@ИапГоревич]

Типо hash-табоица в js?

[@isopp7744]

@@ИапГоревич Да я сам поинтересовался, но hash-таблица - это вроде бы структура данных, разве нет? Он же тут некоторую проверку "чего-то" на "что-то" - условно "оборачивает" функцией.

[@ИапГоревич]

@@isopp7744 А, спасибо!

[@ИапГоревич]

@@isopp7744 Да, это структура данных

[@ИапГоревич]

Я думал, что Инвариант = invariant(не вариативный, т.е. нет изменений в системе)

[@МаксимМакаров-к8б]

Может смени язык на типизированный. Легче объяснять будет

[@ВладимирЧапайкин-у4р]

_Я чё-то наверное, не понял из слов автора. Насколько я вижу, автор НЕ использует здесь особую "фишку" инварианта (или у меня есть предположение, что сам автор чё-то в этой теме недопонимает). Т. е., он мог бы озаглавить видео "предусловие и постусловие", и ничего по сути в логике на видео не поменялось бы (даже если бы предусловие и постусловие отличались)._ _А вот ИНВАРИАНТ (т. е., когда предусловие и постусловие одинаковые) полезен для доказательства правильности циклических (итеративных) конструкций в коде: например, циклов, рекурсивных вызовов подпрограмм (функций). Там фишка в том, что ты доказываешь, что однократное (любое) выполнение цикла (или вызова рекурсии) не меняет инвариант -- и тогда доказано, что цикл работает правильно (если доказана его завершимость). Плюс от инварианта, что (как правило) это доказывать проще. В противном случае (если инвариант найти не удаётся), то придётся доказывать по мат.индукции (что муторно) или каким-то другим способом._ ____________________ _П.С. Доказывать алгоритмы это чисто теория. Не спрашивайте меня, кому это на практике это надо. Никому это на практике не надо! Никто этим не занимается при программировании, не забивайте себе голову._

[@S0ERDEVS]

Для начала погугли "инвариант классов (типов)", "программирование по контракту". В остальном ты просто рассказываешь про "инвариант циклов", что не является единственным применением инварианта.

[@antonschneider4213]

никому??? не все могут себе позволить г**окодить

[@данилдубровин-я8и]

Я вот щас недавно, Кнута пытался осилить, после алгоритма Евклида, потом идёт математическая индукция, так вот инвариантность, это и есть некоторая аналогия математической индукции или как понимать?

[@ezekiel6515]

Сначала прочитал «Инвалид в программировании»

[@Rybkinrolla]

Я вот сижу и слабо представляю себе зачем мне могло бы это понадобиться. Повышать в разы сложность алгоритма различными проверками ради собственной дуракоустойчивости. Если пишешь методы по 200 строк, то возможно там и понадобится, но тогда, мне кажется, что проблему нужно решать с другой стороны. В любом случае, за теоретические знания СПАСИБО. В проверке на то, что сущность является тегом, ты сделал проверку на типы полей, но пропустил проверку, на то что сущность может содержать больше 2 полей.

[@isting4741]

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

[@Rybkinrolla]

@@isting4741 а я и не против тестов, в своих командах я устанавливаю минимальное покрытие в 85%. Но внедрять в бизнеслогику проверки со сложностями n*n, как по мне, абсолютно глупо.

[@isting4741]

@@Rybkinrolla вы правы, конечно, но все равно все зависит от того, что это за бизнес логика и сколько будет стоить необнаруженная ошибка. Если это, например, банковская бизнес логика, то вполне уместно прописать жёсткие конкратны в наиболее важных местах, например, в обработке транзакций, иначе к вам обратиться клиент, у которого со счета списался миллион, хотя он во время перевода нажал на кнопку "отменить" . Просто к этому, как и любой рабочей задаче, нужно подходить с трезвой головой и грамотно оценивать, какие ресурсы вы потратите и какой результат вы получите. Ну а в действительности - да, такого уровня контракты нужны в одном случае из тысячи

[@Rybkinrolla]

@@isting4741 так, а для чего тогда: CI, интеграционные и контракт тесты, если мы тестировать начнём внутри бизнеслогики?

[@isting4741]

@@Rybkinrolla тесты - это когда вы тестируете бизнес логику на конечном наборе данных, пусть этих тестов хоть по 100 на каждый метод, но это конечное и очень малое по сравнению с пространством входных данных количество проверяемых сценариев. Тестирование не даёт вам гарантий абсолютной работоспособности программы на любых входных, только на протестированных. А доказательство инвариантности - это по сути абсолютное аналитическое математическое доказательство корректности. Утрированный пример: вы можете написать 100 тестов на ваш бинпоиск и это не гарантирует, что не существует 101-го набора входных данных, на котором все сломается, а можете написать одно математическое step-by-step доказательство. Может мы с вами друг друга не понимаем? Я уточню, что под контрактным программированием я имею ввиду не показанные в видео рантайм ассерты (это дичь, нужная только для fail-fast), а полноценное математическое доказательство корректности, выраженное либо в коде, если позволяет язык (например, Idris), либо в виде отдельной письменной спецификации, на бумаге или комментариями над каждой строкой кода в формате: PRE, INV, POST

[@AlexYaroshevich]

Соер: Вот тут мы проверки на типы навертели, потому что JS не умеет, но TS умеет, ну в нём другие были бы. Программисты: facepalm. Так покажи другие? 12:35 Мутируешь входные данные, показываешь плохой код 14:15 Вот почему не показать входные данные в виде запроса от пользователя, как в настоящих проектах? 15:25 Не надо выходить из vim, чтобы запустить программу :-( В целом, непонятно зачем нужно знать что именно вот это и есть инвариант. Его нельзя нарушать? И еще непонятно, если бы мы в TypeScript всё это делали, получается, было бы достаточно проверить на входе и выходе типы, скастовать, а всё остальное сделал бы компилятор, и такой пример был бы гораздо полезнее и понятнее, чем проверять типы в рантайме даже не используя стандартные библиотеки ассертов.

[@S0ERDEVS]

1. Так открой глаза и посмотри другие видео на канале 2. Использование ссылок - это не плохой код, подумай на досуге почему параметры не передаются только через копирование. 3. Потому что это учебный код 4. Ты не думал что в монтаже видео есть такая штука как "склейки" и они менее заметны когда есть общие кадры. Или проще - когда ты выходишь в шел, ты можешь поставить склейку и это будет очень органично. Хоть один нормальный вопрос будет?

[@AlexYaroshevich]

@@S0ERDEVS только ты же не ответил, зачем вообще комментировал)

[@S0ERDEVS]

@Alexey Yarrr! ты меня поставил в тупик