Telegram Web Link
Таким образом, связка reset-shift работает аналогично стэку вызовов - каждый вызов функции f перемещает исполнение обратно в блок reset (с результатом, равным аргументу f), при этом запоминая вернуться на инструкцию, следующую за вызовом f.

После завершения блока reset управление передаётся обратно в последний вызванный shift, а возвращаемое значение f становится равным значению блока reset. Завершение всех последующих блоков shift равносильно завершению reset с соответствующим результатом. Именно поэтому результат исполнения всего блока - 3.

Скорее всего, именно из-за размазанной по коду логики, осложнённой проблемами компиляции чего-то посложнее приведённого примера, продолжения в Scala отправились на свалку истории. Тем не менее, идея получила развитие в библиотеке scala-async, наследующей идеи одноимённой парадигмы из языка JavaScript.

P.S. Забавно, что какое-то время Scala-продолжения использовались (а возможно и до сих пор используются) в Forge - API для модов в майнкрафте. И уже в 2015 году с установкой соответствующей библиотеки наблюдались проблемы.
Решил собрать в единый список найденные мной задачи и упражнения, непосредственно связанные со Scala (исключая совсем уж банальный HackerRank). Многие из них могут быть сформулированы и для других языков (верно и обратное), но намного удобнее, когда не нужно заниматься дополнительной интерпретацией.

1. https://www.scala-exercises.org - базовые упражнения в часто используемых Scala-библиотеках. Сравнительно простые, но помогут разобраться с их основными функциями и структурами данных.

2. https://olegpy.com/cats-effect-exercises - 2 задачи на параллельные и конкурентные эффекты от Олега Пыжкова. При необходимости можно воспользоваться подсказками, а "базу" задачи можно сразу запустить в scastie.

3. http://degoes.net/articles/zio-challenge - достаточно интересная задача от Джона Дегоуза на создание балансировщика нагрузки относительно процента наблюдаемых ошибок. В комментариях набралось немало решений, к которым можно обратиться за помощью.

4. http://scalapuzzlers.com - сайт, аналогичный оному для языка Java, с задачами вида "что будет, если написать вот так?". Естественно, разбираются сугубо краевые случаи, к каждому из которых прилагается подробное объяснение.

5. https://www.riddles.io - сайт с соревнованиями на написание ботов, принимающий решения на Scala. Примечательно, что в большинстве соревнований присутствуют непосредственные партии между ботами, для которых даже сделали приятную визуализацию.

6. http://aperiodic.net/phil/scala/s-99 - Scala-адаптация 99 алгоритмических задач для языка Prolog. Не для всех задач есть решение, а их сложность варьируется от нахождения последнего элемента в списке до создания кроссворда заданной формы.

7. https://exercism.io/tracks/scala - раздел, посвященный Scala, на сайте по изучению ЯП. Предлагается более 90 задач возрастающей сложности, причем каждое решение комментируется ментором-человеком. И, да, это бесплатно.

8. https://www.codewars.com - соревновательный сайт с задачами по программированию разной степени тяжести. Scala пока находится в стадии бета-тестирования, зато на Haskell можно решать задачи уже сейчас ;)

9. https://www.codetriage.com - по сути список issue в крупных репозиториях, среди которых присутствуют представители из Scala-экосистемы. Сами "проблемы" предполагается либо смотреть вручную, либо получать случайные в почтовой рассылке.
В процессе поиска интересных упражнений наткнулся на разбор задачи на языке Eta. Примечателен он не столько самим решением, сколько выводами, к которым приходит автор:

1. Язык неидиоматичен относительно jvm, так как автор не справился с разбиением на пакеты в целом и на src/main и src/test в частности.

2. Eta позиционирует себя как Haskell на jvm, а поэтому в нём сложно найти, как сделать нужную вещь, и вместе с тем одну и ту же функциональность можно реализовать разными способами (логика этого пункта не совсем понятна).

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

Несмотря на странность озвученных претензий, с итоговым выводом сложно не согласиться - глобальная роль Eta остаётся неясной, поскольку усидеть на двух стульях (jvm и Haskell) на текущий момент у языка не совсем получается.

К тому же, несмотря на активную работу в репозитории, на сайте Eta можно заметить отсутствие публикаций в блоге и вопросов на stackovervlow за 2019 год, что говорит о спаде интереса сообщества, и до этого не сравнимого с таковым у Scala и Java.

Последнее в особенности внушает опасение, что Eta так и останется проектом, которому не хватило сил, чтобы выбраться из статуса перспективной задумки.
Нашёл занятную библиотеку с не менее занятным названием - goed verhaal - реализующую монаду для отката произвольных эффектов при возникновении исключений.

Saga (а именно так эта монада называется) может быть полезной, если вы встраиваете нетранзакционные действия внутрь ConnectionIO через liftIO или, наоборот, осуществляете транзакции в контексте F[_]. Важно помнить, что откат операции тоже может упасть с ошибкой, но на остальные rollback-действия это не повлияет.

Несмотря на то, что написана библиотека почти год назад, ввиду единственной основной зависимости (cats-effect) она может быть легко скомпилирована с Scala 2.13 уже сейчас. В тестах, правда, придётся избавиться от зависимости на cats-scalatest (или подождать, пока её скомпилируют с 2.13) и удалить несколько флагов компилятора из build.sbt.
Upd: Получил комментарий от автора Saga-монады Марка де Йонга. Библиотеку в будущем планируется дорабатывать, на текущий момент в приоритете документация. Также вполне возможно, что Saga станет частью ZIO (sic!):
P.S. Недавно у Марка вышла заметка Functional Ecosystem с примерами реального кода (в основном связанного с doobie), в которой также присутствуют ссылки на другие познавательные материалы и проекты.
Недавно потребовалось найти клиентскую библиотеку для RabbitMQ и с удивлением обнаружил такую под авторством разработчиков антивируса Avast.

Помимо того, что это одна из немногих поддерживаемых библиотек для взаимодействия с RabbitMQ для Scala, она достаточно неплохо документирована, имеет интеграцию с circe и позволяет подключение метрик из коробки. Но главное, библиотека полностью написана в Tagless Final стиле.

Единственным недостатком является не самое удобное подключение библиотеки - в репозитории предлагается скачать зависимости и поместить их в папку с проектом. Тем не менее, это можно сделать и более традиционным способом - достаточно добавить maven-репозиторий Avast в build.sbt
Порекомендовали познавательный сайт с перечнем принципов, которые могут пригодиться разработчику. Среди них приводится закон Вадлера:
In any language design, the total time spent discussing a feature in this list is proportional to two raised to the power of its position.
0. Semantics
1. Syntax
2. Lexical syntax
3. Lexical syntax of comments

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

Приятно видеть, что при разработке Dotty закон Вадлера смогли обойти - на форуме контрибьюторов едва ли можно найти пост, посвященный комментариям. Тем не менее, судя по тому же форуму, имеет место "закон Одерского", в котором место лексического синтаксиса комментариев занимают изменения, связанные с implicit-параметрами.
Не так давно на официальном канале typelevel появилась запись доклада с интригующим названием "Хотите разнообразить Scala-сообщество?". Несмотря на неоднозначность самой темы diversity, в докладе звучат вполне здравые вещи на тему того, что люди иногда проявляют токсичность, сами того не осознавая.

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

Тезисно было озвучено следующее:

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

- Окончательный выбор докладов для конференции должен делаться на основании их технической составляющей.

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

В результате, был приятно удивлён полученными ответами - на волне бездумного приплетения меньшинств "ради того, чтобы было" подход выглядит весьма адекватным. Полный список вопросов/ответов автор опубликовала в своем твиттере.
Не так давно пришла в голову мысль, что, поскольку я стал заниматься ФП из-за собственного интереса, а не каких-то объективных причин, у меня нет глобального понимания, почему оно "лучше" ООП — просто другая парадигма мышления.

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

Для тех, перед кем вопрос "ФП >? ООП" уже не стоит, статья может быть интересна кратким экскурсом в историю ООП и обилием достаточно забавных цитат.
Месяц назад одним из разработчиков Scala-компилятора Лукасом Ритцем было предложено выбрать единый тестовый фреймворк, который будет по умолчанию поставляться вместе с дистрибутивом Scala.

На фоне наличия чересчур богатых возможностями тестовых фреймворков (ScalaTest, specs2) предложение выглядит более чем адекватно. Однако разработка минималистичного аналога, удовлетворяющего всем необходимым потребностям, может оказаться проблематичной (см. обсуждение).

Одним из компромиссных решений является тестовый фреймворк airspec, позволяющий описывать тесты в виде любимых всеми функций, сохраняя при этом выразительность такого описания.

Для тех, кто ищет удобного DI в тестах, но с опаской смотрит на distage, в airspec найдётся приятный бонус - достаточно простой механизм управления зависимостями предоставляется из коробки, так же как и property-based тестирование.
Не так давно появилась замечательная библиотека parapet - минималистичный аналог Akka, фокусирующийся только на аспекте распределённости. API библиотеки достаточно минималистичен и составлен в TF-стиле, что позволяет использовать любимую IO-монаду из коробки (Task, cats IO, ZIO). При этом, в отличие от Akka, библиотека не является фреймворком, в результате чего под неё не нужно подстраивать остальные части приложения.

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

Несмотря на уже достаточно богатый набор возможностей и активную разработку, сейчас проект находится на начальной стадии развития и ещё нуждается в доработках, в частности - производительности. Хочется надеяться, что со временем проект вырастет и сможет составить конкуренцию таким фреймворкам, как Akka или Reactors.
На днях в комментариях на реддите опубликовали подборку видео о работе компиляторов Scala и Dotty вкупе с книгами о компиляторах вообще. Решил немного дополнить список обзорными видео, поскольку слушать полтора часа про построение деревьев в Dotty может показаться утомительным.

Scalac:
1. Scalac Survival Guide (1 час)
2. A deep dive into Scalac (47 минут)
3. Scala compiler plugins 101 (32 минуты)
4. Scalac micro-optimisation (7 минут)

Dotty:
1. Dotty Internals 1: Trees & Symbols (1.5 часа)
2. Dotty Internals 2: Types (2.3 часа)
3. Dotty Internals 3: Denotations (2.5 часа)
4. Hands-on Dotty — Dmitry Petrashko (1.6 часа)
5. What's Different In Dotty by Martin Odersky (1 час)
6. Integrating IDEs with Dotty (30 минут)

Отдельным пунктом хочу выделить презентацию How an Optimizing Compiler Works (47 минут) под авторством Li Haoyi, в которой затрагиваются основные аспекты работы оптимизирующего компилятора.
Полезный cheatsheet от Филипа Шварца на тему базовых операций Monad, Traverse и Foldable. Отлично подходит для запоминания тем, кто только начинает осваивать эти type-классы.
На этой неделе в поле моего зрения попала статья 5 ЯП, которые должен знать разработчик в 2019 году. В списке, внезапно, присутствует Scala (также рекомендуют и Haskell), но больше всего привлекли моё внимание следующие заявления автора:

-Вы не можете быть программистом без понимания C или C++
(You cannot be a programmer without understanding C or C++)

-Инженеры ПО и разработчики, знающие C, в целом лучше программистов, которые C не знают
(Software engineers or developers who know C are solely better than programmers who don’t know C).

В целом, сложно поспорить с тем, что знание, например, скриптовых ЯП сильно пригождается при решении небольших утилитарных задач (хотя недавний твит от Олега Пыжкова свидетельствует, что и это не всегда так). Тем не менее, даже после прочтения статьи необходимость понимания C и тем более С++ для меня осталась спорной.

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

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

Для более наглядной иллюстрации материала присутствует также интерактивная составляющая, а для самых заинтересованных имеется перечень научных работ про коэффекты.
2025/07/03 08:47:05
Back to Top
HTML Embed Code: