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

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

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

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

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

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

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

Спасибо.

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

спасибо!

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

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

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

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

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

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

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

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

10:45 Оговорка/ошибка в сравнении слабой и сильной типизации? Ведь в ответе подразумевается динамическая и статическая

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

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

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

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

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

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

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

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

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

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

кто-нибудь считал сколько раз произносится слово "инвариант" ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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