В прошлой главе мы перенесли A* на F#, после чего в образовательных целях занялись выдёргиванием его «кишок» наружу. Тогда процесс «потрошения» не был завершён до конца, но сегодня мы его добьём. Что касается метагейма, то мы продолжим путь от функции к конструктору и даже успеем слегка залезть на «ту сторону».
Концепция этого цикла начиналась с простого переноса тайловых миров на F#. Однако в процессе его описания я основательно растёкся по древу, за счёт чего у нас образовался большой подготовительный этап из пяти глав про языковые фичи и прочую «фундаменталочку». Думаю, что с подготовкой закончено, поэтому сегодня мы обратимся непосредственно к тайловым мирам.
Но начнём мы практически с конца — с адаптации поиска пути. Это несложная задачка, но в процессе её решения мы успеем закрепить пройденный материал и по инерции заскочить в новый.
Мы закончили обсуждать тело функции, и теперь пришло время вывода данных. Простые сценарии мы сразу отбросим, так как по ним уже хорошо прошлись, когда изучали выражения. Мы начнём с косяков выполнения, под которыми я подразумеваю не баги, а непреодолимые препятствия с различной степенью неожиданности. Это может прозвучать странно, так как аварийный выход не подпадает под определения output, codomain и т. д. Я с этим согласен и пересматривать эти термины не собираюсь. Однако меня интересует не только легитимная часть, но и вообще всё, что выходит из функции. Вплоть до того, что в следующих главах я начну включать в это аморфное понятие сайд-эффекты, фоновые процессы и много чего другого.
Я начал с ошибок, потому что Godot эту тему фактически проигнорировал, и вряд ли за ненадобностью, так как несколько раз мне уже было очень больно. У меня всё ещё не дошли руки покопаться в GDScript, так что я понятия не имею, вызван ли этот пробел ограничениями языка или архитектурным решением, но в любом случае нам его надо закрывать.
C# и ФП пропагандируют разные подходы к ошибкам. F#, будучи на перепутье, испытывает влияние обоих. Можно много говорить про плюсы взаимного обогащения культур, но судя по публичным баталиям, это не совсем наш случай. Вместо синтеза я куда чаще наблюдаю эмоциональные взрывы в среде представителей то одного, то другого лагеря. Я не буду ввязываться в эту борьбу (в этот раз) и сосредоточусь на решении более насущной задачи. Мне нужно доработать интероп так, чтобы он соблюдал привычную систему распределения ответственности. Так что сегодня только рутина, без красивых ходов и эффектных бросков.
В прошлых частях мы подключились к Godot, обсудили адаптацию к API и разобрались с устройством тела функции. Дальше в планах было перейти к входным и выходным данным, от них к общей архитектуре и далее снова к особенностям API. Если бы я отстрелялся быстрее, то так бы и было, но я возился слишком долго (об этом чуть ниже), из-за чего до моей телеги успел доползти читатель с типовым набором набивших оскомину вопросов. Допускаю, что я собрал всю коллекцию практикующих читателей, но мне хочется верить, что где-то прячется «молчаливое большинство» с аналогичными проблемами. Поэтому я решил передвинуть некоторые рассуждения из конца цикла в середину.
Это задержит кульминацию, но не критично, так как финальные части цикла я планировал запостить без длительных пауз. Поэтому эта глава пролежит в ожидании до тех пор, пока не будет готов черновик всего цикла. Если этот текст появился на Хабре, то остальные главы уже на подходе.
Этой статьёй я хочу внести некоторые правки в алгоритм развёртывания, который я описывал год назад вот здесь. Статья тогда получилась объёмная, и я искал способы её сократить, в результате чего опрометчиво пренебрёг несколькими сценариями, которые пригодились мне в дальнейшей разработке. Они образовали техдолг, который мне необходимо закрыть ввиду грядущего продолжения.
Если бы кто-нибудь сказал мне несколько месяцев назад, что я буду снова экспериментировать с .NET после более чем пятнадцатилетней паузы, то я бы, наверно, рассмеялся1. В начале своей карьеры я пробовал работать с .NET и Java, и хотя некоторые вещи .NET делал лучше, чем Java (у него была возможность научиться на ошибках ранней Java), я быстро остановился на Java, потому что это была по-настоящему портируемая среда.
Наверно, читающие мой блог знают, что последние несколько лет я время от времени экспериментировал с OCaml, и я могу с уверенностью сказать, что он стал одним из моих любимых языков программирования наряду с Ruby и Clojure. Недавно работа с OCaml привлекла моё внимание к F# — это разработанный компанией Microsoft ML (Meta Language) для .NET , функциональная копия объектно-ориентированного (по большей мере) C#. Самый новый ML-язык…
Перевод цикла Скотта Влащина о том, как типы помогают проектировать программы. Первая глава, она же введение, посвящена тому, как делать дизайн прозрачнее и при этом улучшить корректность.
Как-то так получилось, что я никогда не воспринимал Android-телефон как объект, содержимым которого можно управлять из обычного .fsx. Все данные туда и обратно я таскал исключительно ручками при помощи USB и проводника. Дальше на стороне компа их мог раскидывать скрипт, но в зону телефона я не лез. Максимум, мог написать мобильное приложение для систематических операций с загрузкой на сервер и обратно. Однако недавно нужда заставила меня проникнуть из скрипта в обе области сразу, и это оказалось настолько проще, чем я предполагал, что теперь я испытываю злость и сожаление (как будто проморгал выигрышную комбинацию и додавливал противника лишние 4 хода).
Дисклеймер: До этого всё, что я публиковал на Хабре, касалось тем, которые мне известны очень хорошо. Ну или как минимум, затрагиваемое пространство всегда было заметно меньше известного. В этот раз ситуация обратная. Я случайно набрёл на интересную нишу и поверхностно изучил её. Так как я благополучно решил все свои задачи, то вряд ли буду раскапывать тему дальше. Но раз уж мне удалось неявно закрыть несколько запылившихся ишуев на Гитхабе, то мне показалось полезным просуммировать в тексте собранные знания, а также некоторые исторические наработки. Считайте, что я на секунду появился в дверях вашей комнаты, сказал нечто вроде «Посоны, там-то и там-то есть что-то интересное» и свалил.
В прошлой главе мы изучали свойства выражений и их влияние на устройство функций. В некотором смысле это был взгляд на функции снизу вверх. Теперь нам надо посмотреть на них сверху вниз, с позиции алгоритмов. Нас интересует, как алгоритмы существуют в функциях, где располагаются и как преобразуют окружающее пространство. Это широкая тема, но вся она крутится вокруг жизненных циклов процессов и их данных.
В прошлой части я говорил про адаптацию API Godot к F#. Далее в планах было разобраться с общей структурой приложения, но я столкнулся с необходимостью закрыть серьёзный пробел в публичном корпусе текстов. Так что в этой и последующих частях я буду объяснять нечто странное — как из обычной функции путём эволюции получается работающая программа на Godot.
На мой взгляд, у большинства F#-новичков тактический и стратегический уровень находятся в разных вселенных. Типа вот здесь в локальном пространстве у нас ФП, а на глобальном внезапно тащит только ООП. Это, конечно, хорошо, что мы можем склеивать две парадигмы, но мне кажется, что эта непреодолимая стена на границе сферы деятельности ФП не такая уж непреодолимая. Существование её обусловлено не объективными причинами, а недостатком опыта.
В прошлый раз я в основном говорил о трудностях, которые возникают при попытках совместить F# и Godot. Это была вынужденная мера, так как нас в первую очередь интересовало «стандартное» поведение на случай, когда нестандартное и удобное почему-то не сработало. Можно сказать, что мы учились падать без серьёзных последствий перед тем, как научимся совершать броски и болевые приёмы. Нужный ход, если мы не хотим за пару занятий инвалидизировать большую часть группы, но всё-таки это не то, за чем мы пришли в секцию. Теперь пришло время перейти к рутине, а за ней — и к более агрессивным техникам.
Цикл из одиннадцати статей Скотта Влащина, посвящённый вычислительным выражениям (computation expressions) в F#.
Скотт Влащин завершает рассказ о вычислительных выражениях в F#.
Сегодня поговорим про методы класса-построителя, с которыми мы ещё не сталкивались.
Скотт Влащин продолжает рассказ о вычислительных выражениях в F#.
Сегодня мы узнаем, как создавать ленивые вычислительные выражения.
Скотт Влащин продолжает рассказ о вычислительных выражениях в F#.
Отклонимся от основной темы и поговорим, как в вычислительных выражениях можно использовать перегрузку функций.
В прошлой части мы проецировали внешние контракты в DTO на примере REST. В этой будем проецировать методы контрактов в нечто, что позволит вызывать их вот так:
let! issues = gitflic.project.["kleidemos"].["myFirstProject"].issue.GET(limit = 24)
Имитация пути метода вызывает наибольший интерес, однако её реализации будет предшествовать ряд самодостаточных стадий.
В данном цикле я хочу поговорить об одном из вариантов представления REST-клиента. Но я буду обсуждать частное (REST), чтобы использовать его как точку опоры для перехода к общему — проблеме проекций внешних контрактов. В первых двух частях я сосредоточусь на синтаксисе и «архитектурных» ходах, а потом поговорю о генераторах кода. Сложность будет расти с каждой частью, но предлагаемые подходы даже в рамках одной части можно применять независимо. Например, сейчас мы поговорим про DTO (Data Transfer Object), в следующий раз — про перенос методов и их иерархии. Это близкие модули, но их взаимное влияние осознанно будет сведено к минимуму.
Ранее я накатал большой цикл по локальному F#-кодогену и высказал намерение периодически возвращаться к генераторам на примере каких-то узконаправленных задачек. Данный цикл — пробный шар в этом направлении. Он логически вытекает из последних двух частей цикла, так что осилившие «Большой код» смогут посмотреть на уже знакомые концепции немного под другим углом.
Скотт Влащин продолжает рассказ о вычислительных выражениях в F#. Вычислительные выражения очень похожи на монады из Haskell, но у них есть свои особенности.
Одной из необычных особенностей Haskell являются ленивые (отложенные) вычисления. В F# вычисления энергичные, как и в большинстве других языков, поэтому там нельзя просто так взять и "прервать" вычисление.
Но если очень хочется, то можно. В этой статьей Скотт рассказывает, как сделать ленивые вычислительные выражения в F#.
Вычислительные выражения — поистине неисчерпаемая тема. Мы научились возвращать пустые значения, а теперь нам предстоит разобраться, как возвращать множественные. Скотт Влащин рассказывает, как использовать метод Combine.
Шестая статья из цикла про вычислительные выражения. Скотт Влащин начинает рассказывать детали реализация, и это в два раза интереснее, чем раньше.
