F# *

В прошлой главе мы начали разбирать порт тайловых миров на F#, где познакомились с некоторыми малоизвестными возможностями Godot. В этот раз наш прицел сместится с технологических особенностей RenderingServer на обычную бытовуху (бизнес-логика + высокоуровневое рисование).

При этом следует понимать, что код разбираемого проекта предшествовал написанию текста и послужил первопричиной выбора тех тем, что попали в цикл. Поэтому нас ждёт очень много очень простого кода с примечаниями вида «это стало возможно благодаря <штуковине, что мы разбирали в цикле>». Конечно-же, я добавил некоторое количество экзотики, но сегодня наша задача — закончить с рисованием чего-либо (если не считать мини-карты, она вместе с GUI попала в последнюю главу) и собрать все заготовки в подобие игры.

Здесь я (переводчик) собрал ссылки на все части цикла, написанного Скоттом Влащиным. И заодно перевёл предисловие, буквально, три абзаца.

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

Что ж, завершается цикл статей о проектировании, основанном на типах. Скотт показывает изначальный код (короткий) и сравнивает его с финальным кодом (длинным). И объясняет, почему размер — это хорошо.

Есть повод для размышлений!

Можно ли использовать размеченные объединения с одним вариантом (SCDU, Single Case Descriminated Unions) не только со строками, но и с другими типами? Можно ли накладывать бизнес-ограничения на такие штука, как количество позиций в заказе или дата рождения?

Скотт Влащин делится секретами разработки бизнес-логики на языке с алгебраическими типами. Подробности внутри.

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

Разберёмся, как это выглядит в языках с алгебраическими типами.

Я работаю программистом уже более 8 лет, и, признаюсь, никогда не понимал, как на самом деле устроены компьютеры. Поэтому я решил попробовать изучить их работу путём эмуляции. Извините, Бен Итер, я пока не собираюсь ничего создавать.

Пятый пост Скотта Влащина посвящён конечным автоматам (они же машины состояний или даже стейт-машины). Функциональные языки хорошо подходят для реализации конечных автоматов, а конечные автоматы хорошо подходят для реализации бизнес-логики.

Попробуем?

Четвёртый пост из серии Скотта Влащина посвящена предметной области. Как с помощью типов описывать бизнес-правила? Как типы позволяют углубить понимание предметной области?

Узнаем прямо сейчас.

Новая глава из цикла Скотта Влащина. Обсуждаем, как сделать код надёжным с помощью развитых типов из F#.

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

<Картинка не влезла в превью.>

Разобрав её детально, я планирую размашисто закончить этот цикл статей. Хардкора не будет — только применение уже пройденного материала, приправленное малоизвестными техническими деталями движка.

За остаток цикла мы должны выяснить, как можно строить среднеразмерные игровые сцены на F#, а также почему этот цикл называется так, как называется. Конкретно в этой главе мы разберёмся с RenderingServer-ом (бывший VisualServer), но не с нуля, а с позиций достигнутых в «Godot — рисование без правил» и «Прямоугольные тайловые миры». Если вы уже прочитали эти статьи, то вам должно быть известно, что рисование через RenderingServer — это довольно экзотический подход, который воспринимает хождение сквозь стены как рядовое событие. Авторы движка этому не препятствуют, но и не содействуют, поэтому документации по этому серверу — кот наплакал. Мне так и не удалось выудить ответы на все интересующие меня вопросы в словесной форме и их пришлось выковыривать при помощи живых экспериментов. Последние ни в статью, ни в проект не влезли, но тут важна сама парадигма, при которой мы всегда отталкиваемся от практики, а не от теории, которой пока просто нет.

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

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

Дело в том, что на зимних каникулах я ходил в народ и внезапно обнаружил, что в данный момент моему циклу нужно не продолжение, а хорошая пачка «чекпоинтов». Поэтому мне пришлось отложить все заряженные ружья на потом, чтобы зафиксировать текущий прогресс в виде нескольких репозиториев с очень простыми проектами. Собственно разбору этих проектов и будут посвящены оставшиеся части цикла.

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

В следующий раз мы продолжим возвращением к тайловым мирам. Мне вменяли в вину, что в начале цикла я обещал не совсем то, что сделал по итогу, так что я собрал чистовую версию вот такой песочницы спецом под Хабр:

<Картинка не влезла в превью.>

Она написана с применением только тех приёмов, что уже были хотя бы надкусаны в цикле, поэтому концовка получилась очень щадящая.

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

В прошлой главе мы избавились от необходимости непрерывно соприкасаться с C#-генераторами Godot, после чего пришли к выводу, что нам нужен адекватный задаче DSL. Я дам небольшую вводную по написанию самого дешёвого, но при этом крайне эффективного варианта, а все возможные навороты и прочую крутотень оставлю для DLC статей за пределами текущего цикла (иначе он никогда не закончится). Начнём мы с инициализации нод, настройки статических характеристик и выстраивания иерархии, а в следующий раз разберёмся с описанием их поведения.

F# и C# в плане выразительности ООП различаются не так радикально, как некоторым кажется. Но у них разные дефолты, и мы вольны как бороться с ними, так и эксплуатировать их на полную катушку. Для этого необходимо понять, что F#-ный подход ориентирован на симуляцию процессов, а C#-ный — на симуляцию данных. Формально от нас требуется и то, и то, но по моему мнению, моделирование процессов — это 80% моей работы. Оставшиеся 20% — это данные, которые затачиваются под те же самые процессы.

C#-еры то ли обитают в другом мире, то ли как-то пропустили этот момент, поэтому систематически пишут код в обратном направлении — от данных к процессам. Первое время я думал о Godot в том же ключе, но чем больше ковырял <Prefix>Server-ы (там их много, VisualServer — это лишь один из подобных), тем больше у меня складывалось ощущение, что где-то в недрах его команды сидит вменяемый ФП-программист. Уж слишком сильно некоторые решения напоминали наши. К сожалению, я ещё многое не расковырял из того, что нужно расковырять для потенциального разрыва с дефолтным API. Поэтому в рамках текущего цикла мы не будем избавляться от ООП-нагромождений. Вместо этого мы нагородим новых, но так, чтобы нам было удобно работать в ФП-парадигме.

В прошлой главе мы ненадолго прервали изучение синтаксиса F#, но в этой всё с лихвой нагоним, так как сегодня у нас в программе первичный конструктор, расширения типов (снова) и их архитектурные следствия. Я попытался описать их в одном тексте, но обычно они раскиданы по разным частям документации, что серьёзно мешает целостному восприятию, в результате чего даже весьма башковитые ребята тупят как мальчики с Википедией при обсуждении истории древнего Рима. То есть формально у них есть доступ ко всем знаниям человечества, но фактически они соображают слабее, чем человек, прочитавший трижды устаревшего Моммзена.

Начиная с этой главы мы будем постепенно отказываться от того сценария разработки, который предлагает Godot по умолчанию. Итогом отказа будет почти полное исчезновение C# (пока только в рамках проекта) и переход на удобную и идиоматически правильную архитектуру.

Мы ковыряли поиск пути через A* на протяжении двух глав и при этом были сосредоточены на синтаксических изысках F#. В этой главе мы отдохнём от синтаксиса и посмотрим на то, как этот алгоритм мог бы развиваться в более функциональном стиле.

В прошлой главе мы перенесли A* на F#, после чего в образовательных целях занялись выдёргиванием его «кишок» наружу. Тогда процесс «потрошения» не был завершён до конца, но сегодня мы его добьём. Что касается метагейма, то мы продолжим путь от функции к конструктору и даже успеем слегка залезть на «ту сторону».

Концепция этого цикла начиналась с простого переноса тайловых миров на F#. Однако в процессе его описания я основательно растёкся по древу, за счёт чего у нас образовался большой подготовительный этап из пяти глав про языковые фичи и прочую «фундаменталочку». Думаю, что с подготовкой закончено, поэтому сегодня мы обратимся непосредственно к тайловым мирам.

Но начнём мы практически с конца — с адаптации поиска пути. Это несложная задачка, но в процессе её решения мы успеем закрепить пройденный материал и по инерции заскочить в новый.

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

Я начал с ошибок, потому что Godot эту тему фактически проигнорировал, и вряд ли за ненадобностью, так как несколько раз мне уже было очень больно. У меня всё ещё не дошли руки покопаться в GDScript, так что я понятия не имею, вызван ли этот пробел ограничениями языка или архитектурным решением, но в любом случае нам его надо закрывать.

C# и ФП пропагандируют разные подходы к ошибкам. F#, будучи на перепутье, испытывает влияние обоих. Можно много говорить про плюсы взаимного обогащения культур, но судя по публичным баталиям, это не совсем наш случай. Вместо синтеза я куда чаще наблюдаю эмоциональные взрывы в среде представителей то одного, то другого лагеря. Я не буду ввязываться в эту борьбу (в этот раз) и сосредоточусь на решении более насущной задачи. Мне нужно доработать интероп так, чтобы он соблюдал привычную систему распределения ответственности. Так что сегодня только рутина, без красивых ходов и эффектных бросков.