Серия статей с очередным разбором MV* шаблонов, но с интересными деталями
Даже опытные разработчики смогут найти что-то новое для себя
Это третья статья из серии,
в которой подробно разбираем из чего состоит MVI
Статья 3: Из чего готовят MVI
- ⚓️ Парадигма Реактивное программирование (Reactive programming)
- 🌯 Как завернуть все в шаурму Intent?
- 🌽 Как собрать урожай состояние?
- 🚜 Зачем трактору нужен редуктор?
- 🏪 Как открыть магазин с перехватчиками?
- 👷🏼♀️ 5 менеджеров и 1 работник
Основная проблема IT-отрасли, на мой непросвещенный взгляд, заключается в том, что жизнь обучает нас профессии примерно так же, как учителя начальной школы — арифметике. Сначала нам говорят: делить на ноль нельзя. А потом оказывается, что ещё в XVII веке один маркиз по имени Гийом Франсуа Лопиталь научился. Нам говорят: квадратный корень можно извлекать только из положительных чисел. А потом — хоба — оказывается комплексными бывают не только обеды. И так далее.
С чего начинается обучение компьютерным наукам? — С некоторого количества теории, которая скучная и непонятная, как и любая полностью оторванная от практики теория, — а потом — с примеров. Мы открываем REPL и некоторое время забавляемся с ней, как с калькулятором.
Продолжаем погружение в мир функционального программирования! Тема новой статьи — функциональные типы данных и их структуры. Из неё вы узнаете о принципе неизменности данных, о понятии State Machine и о способах его применения в программировании.
А ещё мы исследуем функциональную библиотеку Kotlin Arrow, обсудим поддержку Null, поток данных и функциональную обработку ошибок, а также начнём проектировать Data и Domain слои демонстрационного приложения. В общем, скучать не придётся!
Я не верю, конечно, ни в какую демократию (кроме оригинальной афинской 2½ тысячи лет назад, где кворум состоял из трёх с половиной образованных богатых неглупых людей, а остальные были безголосыми рабами и женщинами). Как я уже где-то говорил, существуют исторические свидетельства того, к чему привели первые проявления этой самой демократии: пару тысяч лет назад люди проголосовали распять одного там назаретянина.
Поэтому когда в качестве аргумента за ту, или иную парадигму, — я вижу какие-то индексы, голосования и прочую статистически значимую оценку vox populi, меня это раздражает. «Миллионы мух не могут ошибаться» — так себе аргумент. Поэтому мнение «коммьюнити разработчиков» — практически всегда облыжное, поверхностное, и, в целом, неверное. У каждого в руках свой молоток, а про многообразие саморезов люди en masse если и слышали, то краем уха и в качестве анекдота.
Если экстраполировать мнение большинства и принять его за аксиому, то в мире будут существовать только банковские приложения и круды с базами данных в качестве узкого места и дополнительными серверами вместо корректного горизонтального масштабирования. Тем не менее, многие даже в своей работе используют инструменты, которым никакая база не требуется, а обеспечение роста гарантируется размазыванием нагрузки по кластеру, а не приклеенными (sticky) сессиями. И я говорю не про десктоп.
Несмотря на то, что сам я ушел из большого ООП¹ более десяти лет назад, причем, надеюсь, навсегда, я всегда крайне вяло и неохотно участвую в баталиях тупоконечников и остроконечников: я абсолютно убежден, что для разных типов задач лучше подходят разные инструменты, и выхолощенное ФП заставит всех вокруг создавать тонны никому не нужного бойлерплейта для тривиального круда, а кристальное ООП — воткнет все возможные палки в колёса при реализации бизнес-процессов. Любой из современных языков программирования позволяет смешивать эти подходы, а микросервисная архитектура — даже гостеприимно приютит несколько языков и сред под одной крышей.
Тем не менее, хотя я никогда не считал себя евангелистом функционального подхода, и уж, тем более, не примыкал к стану воинствующих пуристов, меня постоянно свербил вопрос: что же все-таки не так с ООП, если лично мне быстрее, проще и понятнее — реализовывать свои проекты на функциональном эликсире?
И вот, наконец, меня озарило. Объектная модель всем хороша в однопоточной среде. Даже банальная асинхронность приносит кучу совершенно нерелевантных проблем: мьютексы любого сорта — это порождение дьявола. В игрушечных примерах из книжек они езе как-то работают, но действительно _многопоточный_ код на них написать фактически нереально. Среда, которая буквально приглашает разработчика ошибиться и разрушить тотальность функций потенциальным дедлоком — не должна иметь права на существование в принципе.
В современном обучении программированию, как правило, основное внимание уделяется парадигме объектно-ориентированного программирования (OOP) и вытекающей из неё методологии объектно-ориентированного проектирования (OOD). Определённый ренессанс в наше время испытывает парадигма функционального программирования, но практически никогда в связке с ней не рассматривается функциональное проектирование. Попытаемся осветить наше видение этих вопросов.
Расширяем кругозор. Слышали про парадигму функционального программирования? Если вы iOS-разработчик, то, наверное, да, а если вы Android-разработчик, то, скорее всего, нет. Пришло время это исправить.
Привет! Меня зовут Женя Бондарев. И сегодня мы поговорим о теории функционального программирования, её особенностях и о том, что она может дать вашему Android-приложению. А ещё начнём писать pet-проект на функциональной архитектуре. Поехали!
Содержание:
- Стрелочные функции: arguments, hoisting
- Работа с контекстом
- Методы присваивания контекста
- Обработчик событий
Никто давно не пытается выводить теорий о том как правильно писать код.
Старые теории и способы об этом думать в общественной дискуссии давно свелись к спору о синтаксическом сахаре да и теории те были попыткой выделения каких-то математических свойств кода. Потом как известно была доказана невозможность этого.
Сейчас всё изменилось - мы должны рассуждать о проекте как о том, что постоянно изменяется большими группами людей, какая-то часть и кода и людей может быть неправильной, никто из модифицирующих не знает проекта целиком, нужны новые идеи и способы рассуждения.
В 2021 году Мартин Одерски представил Scala 3. С тех пор экосистема адаптируется, а интерес к ней растет: Scala 3 становится стандартом для новых проектов, в то же время Scala 2 постепенно сворачивается.
В этой статье — наш опыт миграции проекта на Scala 3. Рассказываем, как справлялись с типовыми ограничениями и совместимостью, переписывали макросы и адаптировали популярные библиотеки, и почему архитектура модульного монолита помогла нам пройти этот путь безболезненно.
Поскольку среди тех, кому нравится мой стиль изложения, все еще попадаются люди, не имеющие представления о парадигмах внешнего мира, я решил буквально на пальцах показать, что такое акторная модель, и почему познавшие удовольствие работы с ней крайне неохотно отказываются от неё в пользу больших гонораров и душных офисов.
Рассказ рассчитан на тех, кто хотя бы поверхностно знаком с концепциями ООП и (или) ФП. Ниже вы не найдёте всех тех запутывающих псевдонаучных объяснений, которые вам услужливо предоставит Вика или Анжела (или как там вы называете свою любимую LLM в приватных чатиках).
Текст написан именно сегодня, когда Алану Каю исполнилось 85! Поздравляем, Алан, ты — гений, спасибо тебе за всё!
Все разработчики учились на задачах, в которых вопрос производительности либо не стоит в принципе (тудушечка, гостевуха, что там еще принято делать на первом занятии), либо обозначен непосредственно в условиях задачи (алгоритмика, литкоды, злые преподы).
Потом были первые шаги в качестве стажеров/джунов, с соответствующим подбором задач. Чужой код, подсмотренный в пулл-реквестах признанных в команде асов, — тоже, скорее всего, был максимум асинхронным, и никогда параллельным. Так появляются мифы, один из которых — самый вредный, на мой взгляд, в современном мире, где у каждого в пляжном ноутбуке по триста ядер, — «параллельное программирование сложно».
В самой по себе параллельности ничего сверхъестественного нет: надо просто за недельку привыкнуть к тому, что результат получается не сразу, и всё. Проблема в другом: в том бесчисленном количестве костылей, нагроможденных претендующими (на звание неглупых) людьми, чтобы «упростить жизнь медиокра за клавиатурой».
В любой мало-мальской экосистеме обязательно будет такая штука, как «job runner». Чтобы линейный, простой как полено, код — мог иметь дело с длительными вычислениями. Нужен отчёт, а его генерация занимает полчаса? — Нет, мы не сделаем правильно, не поправим наши схемы, не озаботимся триггерами и persistent views, на это у нас нет ни времени, ни денег, мы стартап, поэтому делегируем: пусть весь неэффективный медленный код идёт в жобу!
Я начал этот небольшой проект под названием isomorphic-validation, как эксперимент, в основном в образовательных целях. Несмотря на то, что существует множество других библиотек валидации, я решил все равно изобрести велосипед. Это была попытка скрыть все сложности, связанные с условными операторами и асинхронностью при создании пользовательского интерфейса...
В статье описан путь преобразования предложенного экспертами Google способа отображения страничных данных с использованием библиотеки Paging3 и Compose от развесистого сборника if'ов и when'ов, вероломно нарушающего все границы архитектурных слоев, до чистого, лаконичного и затягивающего в себя DSL.
В этом монументальном тексте я постараюсь рассказать вам о трёх непревзойдённых шедеврах XX века - математическом языке лямбда-исчисления, языке программирования LISP и спроектированном языке человеческого общения под названием "Ложбан", а также о лежащих в их основе общих принципах и идеях. Кроме того, в конце этого поста я представлю вам свой собственный проект по конструированию языка человеческого общения, в основу которого я положил фундаментальные лингвистические симметрии. Мой проект развивает идеи Ложбана и пытается исправить его недостатки, в мессианской надежде отыскать давно утерянный допотопный язык.
В современном мире невозможно себе представить взрослое приложение, которое не экспортирует телеметрию. Метрики — важнейший атрибут поддерживаемого софта; для всех более-менее профессиональных технических специалистов термин «visibility» давно вытеснил прочие остальные баззворды наподобие «test coverage» и «continious integration».
Примерно двадцать лет назад я впервые узнал о философии отказоустойчивости Джо Армстронга, которая сводится к тому, что инструменты, помогающие разработчику не принести в код ошибку — штука хорошая, но по гамбургскому счету бесполезная, потому что не существует такой приблуды, которая сделает программиста идеальным. Разработчики, даже самые лучшие, будут ошибаться, и первоочередная цель инструментария — минимизировать потери от неизбежных ошибок, а не элиминировать оные полностью. Достижимые цели всегда лучше хрестоматийно правильных.
Отсюда вырос знаменитый «слоган» эрланга «Let It Crash!», высмеиваемый и всегда неверно трактуемый теми, кто неутомимо отслеживает все исключительные ситуации… и спотыкается об отсутствие нужного для их корректной обработки контекста в месте ловли. «Let It Crash» — означает не «Хрен с ними, с ошибками», а «Случилась какая-то ерунда в рантайме, но мы к ней готовы».
¡NB! В тексте нет прямых примеров использования телеметрии в ООП/ФП проектах, но я глубоко убежден, что этот текст будет полезно прочитать, даже если вы просто перекладываете джейсоны из пустого в порожнее на шарпах, котлине или хаскеле.
Сегодня мы поговорим о еще одном, незаслуженно игнорируемом джейсоноукладчиками с узким кругозором, мощнейшем инструменте для работы со структурированными данными. О линзах. Удивительнейшим образом, поиск в интернетах по этому ключевому слову — из внятного — отдает только текст Эрика Эллиота с примерами на джаваскрипте. Эрик — умнейший человек и очень сильный популяризатор, но …кхм… «джаваскрипт, сэр».
Я покажу, как правильно использовать один из самых недооцененных и редко используемых инструментов эликсира — для умной выборки из структурированных данных, а также (на примере собственно библиотеки, куда без этого) — как абьюзить этот механизм для экстравагантных хаков.
Здравствуйте, меня зовут Дмитрий Карловский и я.. придерживаюсь следующей парадигмы мышления: всякое определение должно иметь чёткую границу между тем, что ему соответствует, и тем, что не соответствует.
К сожалению, часто можно встретить споры о пересекающихся определениях, словно они взаимоисключают друг друга. Не менее часто можно встретить ложную дилемму между двумя терминами не покрывающими всё множество сущностей.
Что ж, позвольте внести ясность и предложить вам непротиворечивую классификацию парадигм - подходов к написанию кода, во многом определяющих способ мышления человека по донесению задачи до кремниевого исполнителя.
Так получилось, что загруженный в меня годами разработки опыт привел к нигилизму и отрицанию общемировых ценностей. Например, я ненавижу демократию, самое первое запротоколированное проявление которой привело к решению распять нахрен одного там назаретянина (но сейчас не об этом). Я отрицаю пользу IDE, необходимость развития языков программирования, целесообразность существования паттернов и еще много достижений цивилизации по остаточному принципу.
Зато я являюсь ярым сторонником велосипедостроения. В подавляющем большинстве ситуаций лучше спроектировать и реализовать свой велосипед с перламутровыми пуговицами, чем пытаться приварить оные к выкидышу китайского велосипедопрома. Почему-то среди моих коллег принято относиться к собственным реализациям чего угодно — пренебрежительнее, чем к невнятной библиотеке версии 0.0.1, написанной албанским стажером три года назад по пьяни.
Если разработчик уровня выше стажера считает, что какой-то хрен из интернета уж точно напишет случайный кусок кода лучше него — это не программист, это самозванец, его надо гнать из команды с волчьим билетом.
Около полутора лет назад я опубликовал на Хабре статью под названием "Слово Божие — функциональное программирование как основа Вселенной", в которой я рассказывал про лямбда-исчисление и про то, как программу любой сложности можно свести к алгоритму на базе всего трёх SKI-комбинаторов или же одного единственного йота-комбинатора. В ней мы разобрались с алфавитом божественного языка, на котором написана книга мироздания. Теперь же пришло время разобраться с его грамматикой.
