Эта книга как-то прошла мимо меня. Недавно посоветовали ее прочитать, оказалось, что книга очень годная.
В книге есть пара слов про "ментальное программирование", довольно хорошо написано про UML, приведены основные паттерны проектирования, хоршо описан SOLID. В общем рекомендую почитать шарпистам, особенно новичкам.
Правда, один из авторов - Роберт Мартин, отсюда большое пересечение с другими его трудами и много длинных историй (которые на любителя)
#обзор #книга

https://vc.ru/flood/20942-agile-victims
Хорошая статья про Agile и ожидаемые комментарии "вы просто не умеете готовить".

https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/
Вечно забываю кто виноват в создании NULL, теперь надеюсь будет проще найти

Я считаю, что называть callback признаком функционального программирования - неверно. Но это мнение очень распространенно, мол если есть callback, то это функционально. На самом деле нет и вот почему:

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

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

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

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

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

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

Поэтому математические метафоры в информатике это не 100% матчинаг на первоначальную математическую модель.

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

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

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

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

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

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

Чем хороши монады? Основное их свойство - не нарушать цепочки вызовов, т.е. зная что ваш класс реализует интерфейс монады вы можете с высокой долей уверенности сказать, что он будет корректно вести себя в цепочках вызовов.

Является ли это ФП стилем? На мой взгляд нет. На самом деле интерфейс монады состоит всего из двух методов, причем к ним можно прийти вполне интуитивно, как было сделано в том же итераторе. При этом даже нарушив законы монады, мы не сломаем нашу программу, потому что у нас ООП, а не математика.

Элементарный пример, в законах монады есть ограничение, что применение ID-функции не должно менять содержимое монады. Возьмем пример Array.map(Id) === Array. т.е. Id функция выглядит как-то так Id = (x) => x, если мы теперь нарушим этот закон и Array.map(Id) будет возвращать у нас пустой массив (потому что в нашей программе не разрешены "пустые" действия). Закон мы нарушили, Array перестал "быть" монадой, а наша программа не изменила ни стиль, ни надежность работы.

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

Более того, нарушение законов монады, например в JS Promise, не уменьшает полезности этого инструмента. И не "убивает" надежность программы.

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

Вышло 25-ое архитектурное видео на platform.soer.pro
Тема видео - Архитектурные границы и зависимости
Публичный конспект стрима: https://soer.pro/codelabs/arch_stream_25/index.html?index=..%2F..index#0

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

Некоторые мысли про написание плохого кода.
https://telegra.ph/Vse-pishut-odinakovo-plohoj-kod-06-26-2

Что значит ООП парадигма, как мыслить объектами, а не структурами? Почему одни ООП программы более ООП чем другие?

Если хотите понять что такое ООП то лучшая книга для этого Объектно ориентированное конструирование программных систем. Из всех взглядов (я имею в виду Кея и Страуструпа) объяснения Мейера мне кажутся наиболее интересными и полезными. У него отлично описано контрактное программирование и объектная парадигма. Книга хоть и старая но очень хорошая.

#книга #обзор

Переделал редактор конспектов на platform.soer.pro Давно хотел его сделать чем-то похожим на Jupyter ноутбуки.

Теперь документ - это набор блоков. Блок может быть разных типов, пока только Markdown, но планирую еще сделать код, графики и схемы.

Пока много чего не сделано, но начало положено. Напоминаю, что можно присоединиться к разработке и получить "PRO" за решение issue этой платформы.

Не все читают чат, поэтому продублирую здесь сылку на критику книги "Принципы, паттерны и методики гибкой разработки на языке C#", о которой писал ранее.
https://sergeyteplyakov.blogspot.com/2013/12/about-agile-principles-patterns-and.html

Критика от Сергея Теплякова. Это автор другой книги по С#, который глубоко разбирается в теме. Критика хорошая, но мне кажется вывод о книге все же предвзят, там сильно больше пользы, чем предполагаемого вреда.

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

В программировании есть вещи, которые не стареют. С ASCII графикой в комментариях к коду я познакомился году эдак в 1996, когда подписался в FIDO на NICE.SOURCES. Хорошо запомнил пример с кодом для декодирования JPG, который сопровождался ASCII.

Я заговорил об этом, потому что наткнулся вот на эту статью - https://blog.regehr.org/archives/1653 которая содержит кучу примеров с инфографикой из кода.

У нас есть замечательная группа VK, в которой собираем интересные ролики по программированию. А вот сегодня я там запустил голосование по лучшему ЯП.
Кому интересно вот ссылка - https://vk.com/codeartblog

PS в группе админю не только я, так что претензии по тому что там размещено не ко мне. )

https://www.youtube.com/watch?v=1qtaVMIfqTQ
Выпустил видео про написание функции на TDD + TypeScript. Может кому-то поможет осмыслить разработку через тестирование.

Глас народа )
Жаль, что бот. Было бы интересно посмотреть на уровень этого чувака, может и правда научился бы чему-нибудь полезному.

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

Я прислушался к вашим советам и попробовал на голосовом вводе произнести фразу "please merge two arrays ". У меня получилось следующее " please merge to erase". Я вбил эту же фразу в гугл переводчик и включил произношение, у него получилось следующее " please match two arrays".
А что получается у вас?

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

Хочу поделиться списком рекомендованной литературы для разработчика. За один день такой объем, конечно, не осилить, но как долгосрочная цель - ок.

https://dckms.github.io/system-architecture/emacsway/it/self-education/self-education-for-software-engineer.html

#книга #рекомендация