Таким образом, связка
После завершения блока
Скорее всего, именно из-за размазанной по коду логики, осложнённой проблемами компиляции чего-то посложнее приведённого примера, продолжения в Scala отправились на свалку истории. Тем не менее, идея получила развитие в библиотеке scala-async, наследующей идеи одноимённой парадигмы из языка JavaScript.
P.S. Забавно, что какое-то время Scala-продолжения использовались (а возможно и до сих пор используются) в
reset-shift
работает аналогично стэку вызовов - каждый вызов функции f
перемещает исполнение обратно в блок reset
(с результатом, равным аргументу f
), при этом запоминая вернуться на инструкцию, следующую за вызовом f
. После завершения блока
reset
управление передаётся обратно в последний вызванный shift
, а возвращаемое значение f
становится равным значению блока reset
. Завершение всех последующих блоков shift
равносильно завершению reset
с соответствующим результатом. Именно поэтому результат исполнения всего блока - 3.Скорее всего, именно из-за размазанной по коду логики, осложнённой проблемами компиляции чего-то посложнее приведённого примера, продолжения в Scala отправились на свалку истории. Тем не менее, идея получила развитие в библиотеке scala-async, наследующей идеи одноимённой парадигмы из языка JavaScript.
P.S. Забавно, что какое-то время Scala-продолжения использовались (а возможно и до сих пор используются) в
Forge
- API для модов в майнкрафте. И уже в 2015 году с установкой соответствующей библиотеки наблюдались проблемы.GitHub
GitHub - scala/scala-async: An asynchronous programming facility for Scala
An asynchronous programming facility for Scala. Contribute to scala/scala-async development by creating an account on GitHub.
Решил собрать в единый список найденные мной задачи и упражнения, непосредственно связанные со 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-экосистемы. Сами "проблемы" предполагается либо смотреть вручную, либо получать случайные в почтовой рассылке.
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-экосистемы. Сами "проблемы" предполагается либо смотреть вручную, либо получать случайные в почтовой рассылке.
Scala Exercises
Scala Exercises Is An Open Source Project For Learning Different Technologies Based In The Scala Programming Language.
В процессе поиска интересных упражнений наткнулся на разбор задачи на языке Eta. Примечателен он не столько самим решением, сколько выводами, к которым приходит автор:
1. Язык неидиоматичен относительно jvm, так как автор не справился с разбиением на пакеты в целом и на src/main и src/test в частности.
2. Eta позиционирует себя как Haskell на jvm, а поэтому в нём сложно найти, как сделать нужную вещь, и вместе с тем одну и ту же функциональность можно реализовать разными способами (логика этого пункта не совсем понятна).
В конце концов автор признался, что от процесса программирования на Eta получил удовольствие, а уже на следующий день один из авторов языка в комментариях пояснил, что проект на модули разбить всё-таки можно.
Несмотря на странность озвученных претензий, с итоговым выводом сложно не согласиться - глобальная роль Eta остаётся неясной, поскольку усидеть на двух стульях (jvm и Haskell) на текущий момент у языка не совсем получается.
К тому же, несмотря на активную работу в репозитории, на сайте Eta можно заметить отсутствие публикаций в блоге и вопросов на stackovervlow за 2019 год, что говорит о спаде интереса сообщества, и до этого не сравнимого с таковым у Scala и Java.
Последнее в особенности внушает опасение, что Eta так и останется проектом, которому не хватило сил, чтобы выбраться из статуса перспективной задумки.
1. Язык неидиоматичен относительно jvm, так как автор не справился с разбиением на пакеты в целом и на src/main и src/test в частности.
2. Eta позиционирует себя как Haskell на jvm, а поэтому в нём сложно найти, как сделать нужную вещь, и вместе с тем одну и ту же функциональность можно реализовать разными способами (логика этого пункта не совсем понятна).
В конце концов автор признался, что от процесса программирования на Eta получил удовольствие, а уже на следующий день один из авторов языка в комментариях пояснил, что проект на модули разбить всё-таки можно.
Несмотря на странность озвученных претензий, с итоговым выводом сложно не согласиться - глобальная роль Eta остаётся неясной, поскольку усидеть на двух стульях (jvm и Haskell) на текущий момент у языка не совсем получается.
К тому же, несмотря на активную работу в репозитории, на сайте Eta можно заметить отсутствие публикаций в блоге и вопросов на stackovervlow за 2019 год, что говорит о спаде интереса сообщества, и до этого не сравнимого с таковым у Scala и Java.
Последнее в особенности внушает опасение, что Eta так и останется проектом, которому не хватило сил, чтобы выбраться из статуса перспективной задумки.
Medium
String Calculator Kata using Eta
Whenever I stumble upon a new language the first piece of code that I write is the String Calculator Kata. The beauty of this kata in…
Нашёл занятную библиотеку с не менее занятным названием - goed verhaal - реализующую монаду для отката произвольных эффектов при возникновении исключений.
Несмотря на то, что написана библиотека почти год назад, ввиду единственной основной зависимости (cats-effect) она может быть легко скомпилирована с Scala 2.13 уже сейчас. В тестах, правда, придётся избавиться от зависимости на cats-scalatest (или подождать, пока её скомпилируют с 2.13) и удалить несколько флагов компилятора из build.sbt.
Saga
(а именно так эта монада называется) может быть полезной, если вы встраиваете нетранзакционные действия внутрь ConnectionIO
через liftIO
или, наоборот, осуществляете транзакции в контексте F[_]
. Важно помнить, что откат операции тоже может упасть с ошибкой, но на остальные rollback-действия это не повлияет.Несмотря на то, что написана библиотека почти год назад, ввиду единственной основной зависимости (cats-effect) она может быть легко скомпилирована с Scala 2.13 уже сейчас. В тестах, правда, придётся избавиться от зависимости на cats-scalatest (или подождать, пока её скомпилируют с 2.13) и удалить несколько флагов компилятора из build.sbt.
GitHub
GitHub - vectos/goedverhaal: Deal with failures
Deal with failures. Contribute to vectos/goedverhaal development by creating an account on GitHub.
Upd: Получил комментарий от автора
Saga
-монады Марка де Йонга. Библиотеку в будущем планируется дорабатывать, на текущий момент в приоритете документация. Также вполне возможно, что Saga
станет частью ZIO (sic!):P.S. Недавно у Марка вышла заметка Functional Ecosystem с примерами реального кода (в основном связанного с doobie), в которой также присутствуют ссылки на другие познавательные материалы и проекты.
Недавно потребовалось найти клиентскую библиотеку для RabbitMQ и с удивлением обнаружил такую под авторством разработчиков антивируса Avast.
Помимо того, что это одна из немногих поддерживаемых библиотек для взаимодействия с RabbitMQ для Scala, она достаточно неплохо документирована, имеет интеграцию с circe и позволяет подключение метрик из коробки. Но главное, библиотека полностью написана в Tagless Final стиле.
Единственным недостатком является не самое удобное подключение библиотеки - в репозитории предлагается скачать зависимости и поместить их в папку с проектом. Тем не менее, это можно сделать и более традиционным способом - достаточно добавить maven-репозиторий Avast в build.sbt
Помимо того, что это одна из немногих поддерживаемых библиотек для взаимодействия с RabbitMQ для Scala, она достаточно неплохо документирована, имеет интеграцию с circe и позволяет подключение метрик из коробки. Но главное, библиотека полностью написана в Tagless Final стиле.
Единственным недостатком является не самое удобное подключение библиотеки - в репозитории предлагается скачать зависимости и поместить их в папку с проектом. Тем не менее, это можно сделать и более традиционным способом - достаточно добавить maven-репозиторий Avast в build.sbt
GitHub
GitHub - avast/rabbitmq-scala-client: Scala wrapper over standard RabbitMQ Java client library
Scala wrapper over standard RabbitMQ Java client library - avast/rabbitmq-scala-client
Порекомендовали познавательный сайт с перечнем принципов, которые могут пригодиться разработчику. Среди них приводится закон Вадлера:
Приятно видеть, что при разработке Dotty закон Вадлера смогли обойти - на форуме контрибьюторов едва ли можно найти пост, посвященный комментариям. Тем не менее, судя по тому же форуму, имеет место "закон Одерского", в котором место лексического синтаксиса комментариев занимают изменения, связанные с implicit-параметрами.
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.То есть, каждый последующий пункт в списке будет занимать в 2 раза больше времени, чем предыдущий - больше всего времени уйдет на лексический синтаксис комментариев. Примечательно, что впервые этот закон появился при обсуждении очередной языковой фичи языка Haskell больше 25 лет назад, уже тогда подтвержденный "многочисленными эмпирическими наблюдениями".
0. Semantics
1. Syntax
2. Lexical syntax
3. Lexical syntax of comments
Приятно видеть, что при разработке Dotty закон Вадлера смогли обойти - на форуме контрибьюторов едва ли можно найти пост, посвященный комментариям. Тем не менее, судя по тому же форуму, имеет место "закон Одерского", в котором место лексического синтаксиса комментариев занимают изменения, связанные с implicit-параметрами.
hacker-laws
💻📖 hacker-laws
💻📖 Законы, теории, принципы и модели, которые полезно знать разработчику.
Не так давно на официальном канале typelevel появилась запись доклада с интригующим названием "Хотите разнообразить Scala-сообщество?". Несмотря на неоднозначность самой темы diversity, в докладе звучат вполне здравые вещи на тему того, что люди иногда проявляют токсичность, сами того не осознавая.
Тем не менее, приблизительно в середине презентации появляется слово "токенизм" с призывом приглашать представителей меньшинств выступать на конференции только за то, что они к этим меньшинствам принадлежат. Несколько удивлённый таким предложением, я написал автору доклада в твиттер и попросил разъяснить, что всё-таки имелось в виду.
Тезисно было озвучено следующее:
- Да, в целях привлечения представителей меньшинств предлагается делать им предложения выступить на конференции вне зависимости от их уровня технических знаний и тем докладов.
- Окончательный выбор докладов для конференции должен делаться на основании их технической составляющей.
- Привлечение меньшинств к участию в конференции не означает, что они должны получать преимущество над "белыми гетеросексуальными мужчинами".
В результате, был приятно удивлён полученными ответами - на волне бездумного приплетения меньшинств "ради того, чтобы было" подход выглядит весьма адекватным. Полный список вопросов/ответов автор опубликовала в своем твиттере.
Тем не менее, приблизительно в середине презентации появляется слово "токенизм" с призывом приглашать представителей меньшинств выступать на конференции только за то, что они к этим меньшинствам принадлежат. Несколько удивлённый таким предложением, я написал автору доклада в твиттер и попросил разъяснить, что всё-таки имелось в виду.
Тезисно было озвучено следующее:
- Да, в целях привлечения представителей меньшинств предлагается делать им предложения выступить на конференции вне зависимости от их уровня технических знаний и тем докладов.
- Окончательный выбор докладов для конференции должен делаться на основании их технической составляющей.
- Привлечение меньшинств к участию в конференции не означает, что они должны получать преимущество над "белыми гетеросексуальными мужчинами".
В результате, был приятно удивлён полученными ответами - на волне бездумного приплетения меньшинств "ради того, чтобы было" подход выглядит весьма адекватным. Полный список вопросов/ответов автор опубликовала в своем твиттере.
YouTube
Want to Diversify the Scala Community? Here is How You Can Help! – Yifan Xing
The Scala community has grown significantly over the past 15 years. As a community, we wrote millions of lines of code and developed hundreds of projects. Wh...
Forwarded from Anton Semenov
Не так давно пришла в голову мысль, что, поскольку я стал заниматься ФП из-за собственного интереса, а не каких-то объективных причин, у меня нет глобального понимания, почему оно "лучше" ООП — просто другая парадигма мышления.
К счастью, пару недель назад вышла достаточно подробная критическая статья, раскрывающая недостатки современного ООП. Несмотря на очевидную предвзятость автора, он адекватно рассказывает о слабых сторонах данной методологии, сопровождая это иллюстративными примерами.
Для тех, перед кем вопрос "ФП >? ООП" уже не стоит, статья может быть интересна кратким экскурсом в историю ООП и обилием достаточно забавных цитат.
К счастью, пару недель назад вышла достаточно подробная критическая статья, раскрывающая недостатки современного ООП. Несмотря на очевидную предвзятость автора, он адекватно рассказывает о слабых сторонах данной методологии, сопровождая это иллюстративными примерами.
Для тех, перед кем вопрос "ФП >? ООП" уже не стоит, статья может быть интересна кратким экскурсом в историю ООП и обилием достаточно забавных цитат.
Medium
Object-Oriented Programming — The Trillion Dollar Disaster
OOP is considered by many to be the crown jewel of computer science. The final solution to code organization. The end to all of our…
Месяц назад одним из разработчиков Scala-компилятора Лукасом Ритцем было предложено выбрать единый тестовый фреймворк, который будет по умолчанию поставляться вместе с дистрибутивом Scala.
На фоне наличия чересчур богатых возможностями тестовых фреймворков (ScalaTest, specs2) предложение выглядит более чем адекватно. Однако разработка минималистичного аналога, удовлетворяющего всем необходимым потребностям, может оказаться проблематичной (см. обсуждение).
Одним из компромиссных решений является тестовый фреймворк airspec, позволяющий описывать тесты в виде любимых всеми функций, сохраняя при этом выразительность такого описания.
Для тех, кто ищет удобного DI в тестах, но с опаской смотрит на distage, в airspec найдётся приятный бонус - достаточно простой механизм управления зависимостями предоставляется из коробки, так же как и property-based тестирование.
На фоне наличия чересчур богатых возможностями тестовых фреймворков (ScalaTest, specs2) предложение выглядит более чем адекватно. Однако разработка минималистичного аналога, удовлетворяющего всем необходимым потребностям, может оказаться проблематичной (см. обсуждение).
Одним из компромиссных решений является тестовый фреймворк airspec, позволяющий описывать тесты в виде любимых всеми функций, сохраняя при этом выразительность такого описания.
Для тех, кто ищет удобного DI в тестах, но с опаской смотрит на distage, в airspec найдётся приятный бонус - достаточно простой механизм управления зависимостями предоставляется из коробки, так же как и property-based тестирование.
GitHub
Scala unit testing library proposal · Issue #641 · scala/scala-dev
Authors: @dwijnand, @eed3si9n This proposal seeks to work with the community, particularly the authors and maintainers of testing libraries, in order to introduce a basic, zero-dependency unit test...
Не так давно появилась замечательная библиотека parapet - минималистичный аналог Akka, фокусирующийся только на аспекте распределённости. API библиотеки достаточно минималистичен и составлен в TF-стиле, что позволяет использовать любимую IO-монаду из коробки (Task, cats IO, ZIO). При этом, в отличие от Akka, библиотека не является фреймворком, в результате чего под неё не нужно подстраивать остальные части приложения.
Взамен концепции актора parapet оперирует процессами и каналами. Аналогично акторам, процессы занимаются обработкой и передачей сообщений, однако их также можно можно различным образом комбинировать или выстраивать пайплайны, что во многом напоминает потоки в Akka-streams.
Несмотря на уже достаточно богатый набор возможностей и активную разработку, сейчас проект находится на начальной стадии развития и ещё нуждается в доработках, в частности - производительности. Хочется надеяться, что со временем проект вырастет и сможет составить конкуренцию таким фреймворкам, как Akka или Reactors.
Взамен концепции актора parapet оперирует процессами и каналами. Аналогично акторам, процессы занимаются обработкой и передачей сообщений, однако их также можно можно различным образом комбинировать или выстраивать пайплайны, что во многом напоминает потоки в Akka-streams.
Несмотря на уже достаточно богатый набор возможностей и активную разработку, сейчас проект находится на начальной стадии развития и ещё нуждается в доработках, в частности - производительности. Хочется надеяться, что со временем проект вырастет и сможет составить конкуренцию таким фреймворкам, как Akka или Reactors.
parapet.io
Parapet - A purely functional library to build distributed and event-driven systems
На днях в комментариях на реддите опубликовали подборку видео о работе компиляторов 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, в которой затрагиваются основные аспекты работы оптимизирующего компилятора.
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, в которой затрагиваются основные аспекты работы оптимизирующего компилятора.
Reddit
From the scala community on Reddit
Explore this post and more from the scala community
Полезный cheatsheet от Филипа Шварца на тему базовых операций
Monad
, Traverse
и Foldable
. Отлично подходит для запоминания тем, кто только начинает осваивать эти type-классы.На этой неделе в поле моего зрения попала статья 5 ЯП, которые должен знать разработчик в 2019 году. В списке, внезапно, присутствует Scala (также рекомендуют и Haskell), но больше всего привлекли моё внимание следующие заявления автора:
-Вы не можете быть программистом без понимания C или C++
-Инженеры ПО и разработчики, знающие C, в целом лучше программистов, которые C не знают
(Software engineers or developers who know C are solely better than programmers who don’t know C).
В целом, сложно поспорить с тем, что знание, например, скриптовых ЯП сильно пригождается при решении небольших утилитарных задач (хотя недавний твит от Олега Пыжкова свидетельствует, что и это не всегда так). Тем не менее, даже после прочтения статьи необходимость понимания C и тем более С++ для меня осталась спорной.
В связи с этим, возник вопрос - насколько знание этих языков реально пригождается тем же скалистам в профессиональной деятельности? Речь идёт, естественно, не столько о синтаксисе, сколько об языках в целом: общие принципы написания программ на языке, основные паттерны, механизм сборки и т.д.
-Вы не можете быть программистом без понимания 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 и тем более С++ для меня осталась спорной.
В связи с этим, возник вопрос - насколько знание этих языков реально пригождается тем же скалистам в профессиональной деятельности? Речь идёт, естественно, не столько о синтаксисе, сколько об языках в целом: общие принципы написания программ на языке, основные паттерны, механизм сборки и т.д.
Learn Worthy
Top 5 programming languages every programmer should know in 2019 | Learnworthy.net
Top 5 programming languages every programmer should know in 2019 are Python, Java, C, JavaScript and Scala. These are a must if you want to succeed
В процессе поиска информации про коэффекты обнаружил страницу под авторством Томаса Петричека с одноимённым названием coeffects, возникшую как дополнение к его докторской диссертации.
Сайт представляет собой отличный пример подачи материала - есть возможность как кратко ознакомиться с тематикой, так и углубиться в теоретическое основание или же, наоборот, практическое применение.
Для более наглядной иллюстрации материала присутствует также интерактивная составляющая, а для самых заинтересованных имеется перечень научных работ про коэффекты.
Сайт представляет собой отличный пример подачи материала - есть возможность как кратко ознакомиться с тематикой, так и углубиться в теоретическое основание или же, наоборот, практическое применение.
Для более наглядной иллюстрации материала присутствует также интерактивная составляющая, а для самых заинтересованных имеется перечень научных работ про коэффекты.
tomasp.net
Coeffects: Context-aware programming languages
Interactive essay that explains theory of coeffects and lets you type-check and run sample programs.