2 reasons, why your programs are complex, part 1

Scientific work github.com/pap...
Support channel: / seniorsoftwarevlogger
WebSite: seniorsoftware...
Metch: teespring.com/...

[@SeniorSoftwareVlogger]

Вторая часть kzbin.info/www/bejne/nnjVY4KpqbiVfc0

[@predaytor]

Я всегда знал что Киану Ривз знает русский.

[@olehigorovich474]

Это Джон Уик

[@Elledan3101]

@@olehigorovich474 они забрали его исходники, он забрал их жизни ;(

[@SeniorSoftwareVlogger]

Это скриптонит, вы попутали.

[@yehornaumenko2183]

@@SeniorSoftwareVlogger Ого! Вы даже знаете о существовании таких персонажей)

[@SeniorSoftwareVlogger]

@@olehigorovich474 нет, Джон Сноу!

[@kirillamber6056]

Лучше подкреплять минимальными иллюстрациями. Так лучше воспринимается и запоминается инфа.

[@SeniorSoftwareVlogger]

Ждун не сработал? :(

[@kirillamber6056]

@@SeniorSoftwareVlogger Так это ж просто перебивка, бро). Блогеры так делают, но у них информация не замысловатая.

[@myashik86]

Спасибо! Побольше бы таких светлых голов! Всё по существу и очень лаконично.

[@olehdiatlenko4463]

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

[@stan5214]

Дима твои иконки у монитора это просто бомба! Повешу такие в машине:)

[@teftelpastalog7667]

Интересная тема! Терпеливо жду продолжения.

[@IceKorm]

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

[@alexeym8019]

Отличное видео. Информативно и четко. Больше столь же шикарного интересного контента.

[@КостянЕрмаков-е9ю]

Димка молодец, скоро можно будет с полтинником (не лет😂) поздравлять.

[@dmytro-skh]

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

[@SeniorSoftwareVlogger]

Спасибо! Что ты подчерпнул из этого видео для себя?

[@anna_silver_moon]

очень интересно, жду продолжения!

[@agudulin]

informal reasoning больше звучит как интуитивный ход мысли, не всегда логически верный formal reasoning - наоборот, дедуктивный, логичный ход мысли как они объясняют в своей работе термин, чем больше информации доступно, тем более точны твои догадки о работе системы [стр 4]

[@anton.k.]

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

[@citizen4_223]

Крутая "троица" под большим монитором! Иконки на 5+

[@sergeyspitsyn3220]

Где продаются такие?

[@SeniorSoftwareVlogger]

Пиконка.ру

[@ВладимирМолчанов-ь8б]

15 минут очевидных вещей. А кто-то целую научную работу еще про это написал ))

[@BohdanVR666]

В названии видео вопрос поставили так, как будто в этом видео автор будет для совсем далёких объяснять, почему программирование такое тяжёлое

[@ilyal2066]

Отличное видео, спасибо! Идеальный формат, чтоб смотреть в конце рабочего дня и узнавать новое :D Но мне кажется, вы довольно предвзято отнеслись к ООП. Если вы говорите про неочевидное изменение состояний объектов через их методы, то это пример плохо продуманного интерфейса, аналогичные примеры плохого кода можно найти и в функциональном программировании, никакая иммутабельность не спасет :) Все же в идеале ООП пытается поделить большое и сложное состояние программы, состоящее и кучи переменных и массивов, на более простые и понимаемые состояния объектов. Поэтому я не совсем согласен, что оно проигрывает 0-2

[@SeniorSoftwareVlogger]

Это не я, а авторы, но я тоже, да. ООП - тупик :)

[@MityaEr]

Спасибо за видос и разбор.

[@temcodes]

Давай больше видео!

[@hdhdhhdhdhhdhdh3203]

Наконец-то годнота

[@a.khakimov]

Действительно интересно. Именно этим я и занимаюсь на работе - боюсь со сложностью. Обычно придерживаюсь следующих принципов: - принцип единственной ответственности (класс или метод выполняют только одну функцию) - класс имеет не более 5-8 методов - функция (метод) имеет не более 30 строк - функция (метод) имеет одну точку входа и одну точку выхода Дмитрий, напишите пожалуйста полное название статьи и фамилии авторов.

[@SeniorSoftwareVlogger]

ссылка же в описании

[@a.khakimov]

@@SeniorSoftwareVlogger прошу прощения, не заметил

[@vollthegreat1647]

А откуда эти принципы? Хочется узнать почему методов 5-8 а строк, ровно 30 а не 25...

[@a.khakimov]

@@vollthegreat1647 Это все я вынес для себя после чтения определенного количества литературы, общения с коллегами и в целом из своего опыта разработки. Просто у меня изначально проблема была как раз в том, что я писал очень сложные программы, когда один класс мог делать все сразу (быть каким нибудь многопоточным синглтоном адаптером который одновременно парсил json и строил графики), потом я постепенно ушел от этого. А 30 строк рекомендовал не превышать один из статических анализаторов кода.

[@vasi1iska]

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

[@dmitrypichugin7449]

ООП полюбому как то да снижает сложность ПО, для этого и придумано. Ближе к реальности чем наборы функций, по которым гоняются данные (для больших приложений). Хотя с точки зрения авторов из ролика, именно как стейтлес, да, тут не проще. Я исхожу из книг: 1) Крэг Ларман - ООА/Пэ 2) Гради Буч - ООАиПэ 3) Роберт Мартин - Чистая архитектура (который в своих докладах говорит что будущее за функциональщиной, старайтесь больше кода писать в стейтлейс классах).

[@SeniorSoftwareVlogger]

Авторы выделяют 2 основные причины и с ними ООП не помогает. С более мелкими причинами - конечно, но это все равно, что трупу прививки ставить.

[@dmitrypichugin7449]

​@@SeniorSoftwareVlogger Спасибо за ответ. ООП-шников не бомбит :) Не хочу судить о том чего не знаю, читать 66 страниц не охото, но прослушаю ваш пересказ до конца и там подумаю. Все равно два человека постарались, продумали, много литературы в ссылках указали, интересно к чему пришли. P.S. видео поставил +, как и на все другие :)

[@toooldtobejunior]

ООП помогает разбить как состояние так и управление потоком на мелкие кусочки, которые будут удобнее для восприятия человеком. Таким образом использование ООП помогает снизить субъективную сложность кода. Тем не менее объективная сложность никуда не уходит. Состояние как было изначально так и осталось. И поток тоже

[@dmitrypichugin7449]

Согласен, стейт никуда не денется, и поток как таковой тоже, об этом выше тоже указал. Интрига сохраняется, очень жду продолжения. Хоть работе уже 13 лет, и основное что могло произойти уже произошло, но все равно.

[@SharplEr]

Всё это очень абстрактные размышления, которые разбиваются о детали. Взять хотя бы тему управления ресурсами: как в чистом ФП языке выглядит аллокация в heap? Это операция с сайд эффектом - она мутирует кучу общую для всех потоков. Тут два варианта: либо обернуть это в IO монаду, но тогда синтаксис языка станет настолько перегруженным, что писать на нем станет невозможно, либо придётся использовать GC, который предоставит синтаксический сахар для этой операции и она будет выглядеть для программиста не мутирующей. Теперь сделаем маленькое предположение, что мы пишем highload и посмотрим на подобные Java проекты, где тоже есть GC. Мы увидим, что они не редко используют offheap по соображениям производительности. Надо понимать, что ручное управление памятью в языке с GC это а) так же "удобно и безопасно" как в чистом C б) убивает всю идею ради чего мы использовали GC. Ну и просто хочется задать вопрос: существует ли бизнес логика, которая на C++ выглядит сложнее, чем offheap на хаскеле? Мне кажется, что правильный ответ "нет". И это мы даже не коснулись вопросов управления открытыми файлами/соединениями или кешированием: управление ресурсами не ограничивается только heap-ом. Что касается пролога и других декларативных языков. Действительно код может выглядеть в некоторых случаях понятнее, но что если он вдруг затормозит? Пролог не гарантирует, что выведит самый оптимальный путь вычисления результата и тут возникает вопрос: что проще написать циклик явно в C++ в том виде в каком ты хочешь что бы вычисления прошли или написать такие предпосылки, что бы по ним компилятор пролога сгенерировал именно ту последовательность шагов, которая тебе нужна? Вот я думаю, что первое проще. Вообще по моему опыту программы сложные когда авторы не знают о правильных инструментах/структурах данных либо когда слишком увлекаются всякими парадигмами.

[@SeniorSoftwareVlogger]

Авторы в курсе

[@Amisare_1337]

Спасибо, как всегда за качественный выпуск! Очень интересное эссе, жду продолжение. Только один вопрос: нафига этот пролет камеры над клавиатурой и блокнотом? :))

[@SeniorSoftwareVlogger]

отвлечь внимание от нео в кадре

[@spinacker16]

я все думал на кого он похож. И вспомнил Билли Руссо (Jigsaw) из Карателя (Нетфликс)

[@septembercult985]

Иконки топ!

[@Павел-г6ъ]

Привет,учим с другом php,хотелось бы узнать в чем фишка ООП подхода в php ,и как выставить приоритеты в изучении стека технологий в области web

[@g.n._]

Почему ООП не влияет на сложность? Всегда считал, что его основная фишка - снижение взаимосвязей объектов. И общая сложность системы получается как сумма, а не произведение сложности ее частей. Функционально программирование, как мне кажется, больше всего применяется в data science, но там тоже никто не мешает его комбинировать с ООП при необходимости.

[@SeniorSoftwareVlogger]

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

[@SpiritVoodoo]

@@SeniorSoftwareVlogger мне сейчас показалось что тут есть небольшая подмена понятий. Собственно как помогает ФП язык избавиться от проблем с тем же состоянием? Я всегда на Scala могу напилить кучу мутабельных функций забив на чистые функции, и тоже самое наоборот я могу сделать на java с точностью до наоборот кучу immutable классов с чистыми функциями. Может я конечно что-то не правильно понял.

[@SeniorSoftwareVlogger]

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

[@SpiritVoodoo]

​@@SeniorSoftwareVlogger ну я это и имел ввиду. А вот на тему silver bullet я все же считаю что каждой задаче нужен свой инструмент, просто как бы идея и мысли правильны, но оторваны от контекста решаемой проблемы. По теме есть неплохие рассуждения тут, возможно будут полезны и интересны: habr.com/ru/post/247285/ и habr.com/ru/post/338136/ В поединке между медведем и крокодилом решающим фактором выступает местность. - иногда их микс очень даже не плох)

[@chief-vibe-officer]

InExtremo первая статья это дичь какая-то, как написали в комментах, софистика. А вот вторая довольно интересная, но немного не по теме, имхо. Понятное дело, что можно парадигмы ООП и ФП можно использовать вместе, но там не было ни слова про сложность программ. Как сказано в бумаге, есть состояние и поток - источники сложности. И мы должны максимально приблизить их к предметной области. То есть если данные (состояние) есть в реальной жизни, значит оно должно быть и в программе, и без этого никак. Соотвественно, если мы описываем конкретное решение, мы обязаны отразить предметную область. Как я сейчас догадываюсь (в данный момент нахожусь в процессе чтения), они подводят к тому, что нужно использовать такой подход, при котором нам не нужно будет описывать состояния и процессы, которых нет в предметной области.

[@blue_lobster_]

Клас, дуже класно, що ти ведеш ці відоси

[@SeniorSoftwareVlogger]

Я не говорю по украински.

[@blue_lobster_]

@@SeniorSoftwareVlogger извиняюсь :) Хорошие у тебя видео, очень качественные - это очень круто :)

[@SeniorSoftwareVlogger]

Нет проблем :)

[@programisli]

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

[@SeniorSoftwareVlogger]

Ссылка на работу под описанием

[@SeniorSoftwareVlogger]

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

[@programisli]

@@SeniorSoftwareVlogger Я ничего плохого в черном ящике не вижу. Это нормально, когда состояние прячется. Ключ заводит автомобиль (вызывает функцию старт). Состояние запуска сохраняется в автомобиле, а не в ключе и ключу должно быть все равно, какие там внутренние механизмы работают, чтобы машина ехала.Но вы меня заинтересовали этим видео и я ищу теперь информации понять, что я теряю и где я что-то не понимаю. Но пока из того, что я вижу - ООП как раз помогает, потому что не нужно тестировать все состояние и не нужно заботиться о внутренней реализации (а этом и соль). В любом случае, спасибо за ответ.

[@SeniorSoftwareVlogger]

Это не важно пока тебе не нужно починить автомобиль.

[@programisli]

@@SeniorSoftwareVlogger Спасибо, посмотрю

[@mazdon4ic]

Он 365487 раз моргнул

[@mixed7991]

Почему он так часто моргает?

[@АлександрИванов-п9ы8ж]

M1xed видимо свет в глаза херачит

[@JohnPoison]

Забыл про декларативное программирование. По моему опыту его гораздо проще понимать. Хотя свои проблемы тоже есть.

[@SeniorSoftwareVlogger]

В работе не было примеров. Какие есть примеры реальных декларативных языков?

[@JohnPoison]

@@SeniorSoftwareVlogger QML, в Qt используется активно для построения интерфейсов. Конечно без мутаций не обойтись, поэтому там сложные вещи, не покрываемые декларативной парадигмой пишутся на JS.

[@SeniorSoftwareVlogger]

@@JohnPoison Это тьюринг полный язык общего назначения? Больше похоже на DSL

[@JohnPoison]

@@SeniorSoftwareVlogger это суперсет JavaScript'a. На нем вполне можно писать программы :). Так или иначе, не придираясь к словам, декларативная парадигма, как мне кажется, вполне тянет на упоминание, как способ борьбы со сложностью программы. Мы же не только чисто о языках говорим. DSL -- тоже средство борьбы со сложностью, и он тоже следует декларативному подходу. Те же байндинги в MVVM, или какойнибудь RX -- вполне декларативная вещь, говорящая **что** ты хочешь получить, а не как. Поэтому, написав достаточный набор примитивов, можно декларативно описывать многие вещи, что будет снижать когнитивную нагрузку, при понимании программы.

[@kep261]

то чувство, когда сидишь, думаешь как спроектировать софт, как приблизиться к S.O.L.I.D. и тд и выходит видос о сложности и успеваешь к надписи "нет просмотров")

[@kep261]

@Danila Bagrov странные вопросы. Скачал, распечатал работу, читаю.

[@RomPavel1]

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

[@WyemondMov]

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

[@RomPavel1]

@@WyemondMov Мне кажется, что я консервируюсь в рамках одного проекта.

[@teftelpastalog7667]

Есть смысл делать параллельно собственный проект.

[@pavlomiklashevych1758]

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

[@SeniorSoftwareVlogger]

Если английский в порядке можно исходник прочитать. Лучше чем они написали я все равно не скажу

[@sergzach]

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

[@SeniorSoftwareVlogger]

Да, для программирования интерфейса в функциональном программировании есть монады

[@kudjij]

Крутой бонсай!

[@MainS_YT]

Состояние лайка - поставлен

[@che1011]

Подскажите пожалуйста! Уже изучил фронт-енд, и могу спокойно верстать. Стоит далее изучать back-end или улучшать фронт-енд?

[@SeniorSoftwareVlogger]

Спокойно верстать это ещё не фронтенд. Особенно в современных реалиях. Нужно ещё какой нибудь фреймворк знать. React или Vue, или Angular

[@kingman1299]

Привет. Можешь подсказать, ruby будет актуален в ближайшем будущем?

[@SeniorSoftwareVlogger]

Я не знаю

[@IMPEXize]

Дмитрий, вопрос немного не по теме. Какое Вы используете кресло/стул?

[@SeniorSoftwareVlogger]

Какая-то шляпа из икеи. В списке на замену.

[@radiomode8568]

спасибо

[@РодионГаврилов-ч9ж]

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

[@sumrakx9229]

Если не боишся сложностей, сейчас проблема что даже домохозяйки за 50 идут в программирование "ведь оно меняет жизнь". Под трудностями я предлагаю не сложно, а "пиздец что за хуйня нихачу жить лучше сдохнуть" и так года 2 точно. Иди вопщем если не сломаешся станешь.

[@РодионГаврилов-ч9ж]

sumrak x просто я работал в сфере питания 4-5 лет- дошел до шефа, и проработал им 2 года. Потом пришлось уйти по причине здоровья. Сейчас тружусь на батю аля «парень с завода» собираю станки ЧПУ, но выполняю в основном грязную работу( варить, пились, сверлить и т.д.) батя учить не собирается чему то новому . Так и сказал- учи сам. А мне как бы эта сфера не особо интересна.. в поварскую деятельность не тянет, но готовить люблю и всегда эксперементирую с этим.. я сам не знаю еще насколько программирование «для меня» , но чувствую что может понравиться. Вроде как привлекает бэкенд, но решил начать с фронтенда, чтобы понять вообще что да как работает..

[@sumrakx9229]

@@РодионГаврилов-ч9ж не напутствие, а пища для размышлений. Если нравится линукс и что-то знаешь про пайтон сис админ неплохой вариант и через лет 7 в devOps при умеренном задротстве.

[@_Yaroslav]

Начинай с хекслета. Там новичков на серьёзный уровень выводят.

[@apdgslfhsodbna]

ООП в каком-то смысле помогает понять основную структуру программы и позволяет ее удобно масштабировать в отличии от функционального подхода. Вот я разбирался с программой WinAPI для работы с FAT32, мало того, что структура фат не совсем понятна )) так еще и все прелести API )) ад какой-то для понимания.

[@SeniorSoftwareVlogger]

Winapi как-то связано с ФП?

[@apdgslfhsodbna]

@@SeniorSoftwareVlogger , как бы это тот же Си

[@SeniorSoftwareVlogger]

Си это ж имеративщина. Где это функциональный язык? Там адреса переписывать можно даже а не просто значения.

[@apdgslfhsodbna]

@@SeniorSoftwareVlogger , все, я разобрался в терминах, пасиб.

[@outsider2140]

Благой труд

[@avantipro]

Спасибо, это ахуенно

[@ВасилийЦыганов-ъ6ш]

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

[@SeniorSoftwareVlogger]

Авторам научной работы?

[@ВасилийЦыганов-ъ6ш]

@@SeniorSoftwareVlogger Автору канала.

[@SeniorSoftwareVlogger]

Автор прочитал работу и знает как побороть сложный код. Об этом он рассказывает в серии этих видео.

[@olezhonnv3215]

Авторы этой работы где живут? В идеальном сферическом вакууме? Или в недискретном скалярном поле? Состоянием им тяжело управлять! Вот же ж страдальцы какие, ай-ай-ай! Ну вот есть физика. Там все так просто? Это легко понять? Тысячелетиями изучаем и все никак не разберемся толком. Или какое-то производство. Там тоже процессы могут быть сложные, зависящие друг от друга. А программы пишутся для решения конкретных задач, поэтому там есть состояния, есть сложность. Если кто-то не дорос умом что-то понять, то это его проблема. Процесс от этого проще не станет.

[@ilyabielov9864]

О чём он говорит?

[@Programming_together]

Привет! Ты пиарил мой канал? Если да, то расскажи хоть, где и как :)

[@SeniorSoftwareVlogger]

Привет, Оля! Да, я кинул ссылку в Community tab kzbin.info/door/X3w3jB05SHLbGjZPR0PM6gcommunity?lb=Ugy1RBfcZWsakbkwjVF4AaABCQ :) Надо еще в телеграм запилить.

[@Programming_together]

про меня писали в пабликах ВК по 100к человек, но пока что даже за 1 день ты уже переплюнул их по количеству пришедших :) И ни одного оскорбляющего комментария! У тебя огненная публика :) Спасибо огромное

[@DmitryMagur]

Привет, тут митапчик будет www.meetup.com/ru-RU/phpugmunich/events/mttrspyzcbfc/ Он хоть и пхпшный но про функциональное программирование как раз, приходи!

[@ivanegorov8240]

найс

[@Serjgap]

а чего так моргать стал часто? вроде раньше как обычный человек был

[@SeniorSoftwareVlogger]

Надо очки как у тебя купить, чтобы не палиться

[@ПетроКобзар]

Почему столько клипаете? Что с глазами? Жизнь програмиста имеет побочные ефекты? Не правда ли...

[@SeniorSoftwareVlogger]

Клипаете? Моргаете? Жизнь программиста это не малина, я уже устал об этом говорить. Все равно лезут

[@ПетроКобзар]

@@SeniorSoftwareVlogger Так может вам пора к врачу сходить?

[@SeniorSoftwareVlogger]

@@ПетроКобзар как правильно заметили в другом комменте, чаще моргаешь когда глаза сохнут. Сейчас зима, у меня в комнате 44% влажности, это маловато. Нужно купить увлажнитель на самом деле.

[@EshkinKot1980]

JavaScript не имеет ни какого отношения к объектно ориентированной парадигме, если вы говорите такое, то ООП вообще не понимаете.