Функциональное программирование *

Привет! Я Юля, DevRel в Tinkoff.ru.

28 сентября Tinkoff вместе со Scala-сообществом России провели масштабную, но очень уютную встречу разработчиков, тестировщиков и всех неравнодушных к Scala. В статье я поделюсь впечатлениями, как все прошло.

Сначала — пара слов о том, для чего мы активно включаемся в такие мероприятия. Просто мы любим Scala, используем этот язык и очень хотим, чтобы сообщество развивалось и пополнялось интересными людьми.



Мы ушли от стандартного формата конференций и собрали ламповую встречу для близких по духу людей. Мы нашли самый уютный лофт в сердце Москвы — Deworkacy в «Красном Октябре» — и пригласили по-настоящему звездный состав спикеров.

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

Небольшой видео-пруф, передающий настроение: youtu.be/ThmyLu7kOFk

Ссылки на видео докладов, фотоотчет и описание докладов под катом. Погнали!

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

Зарегистрировавшись в системе, моё внимание сразу привлекла возможность решать задачи на Haskell. Дело в том, что я хоть и увлекаюсь программированием на этом языке, но не продвинулся дальше реализации задач из различных курсов образовательных on-line платформ. Решив, что их решение может оказаться интересным вызовом и повысит мой уровень, как разработчика, я приступил к их решению.

Кому интересно, что в итоге из этого вышло, добро пожаловать под кат.

Комментарий от переводчика: Это перевод замечательной статьи Дэна Абрамова (Dan Abramov), являющегося контрибутором React. Его примеры написаны для JS, но будут одинаково понятны разработчикам на любом языке. Идея общая для всех.

Вы слышали об алгебраических эффектах?

Мои первые попытки выяснить, кто они такие и почему они должны меня волновать, оказались безуспешными. Я нашел несколько PDF-ов, но они еще больше меня запутали. (Я почему-то засыпаю во время чтения академических статей.)

Но мой коллега Себастьян продолжал называть их ментальной моделью некоторых вещей, которые мы делаем в React. (Себастьян работает в команде React и выдвигал немало идей, среди которых Hooks и Suspense.) В какой-то момент это стало локальным мемом в команде React, и многие наши разговоры заканчивались следующим:

Оказалось, что алгебраические эффекты — это крутая концепция, и она не так страшна, как мне вначале показалось после прочтения этих PDF-ов. Если вы просто используете React, вам не нужно ничего о них знать, но если вам, как и мне, интересно, читайте дальше.

Обобщенные асинхронные типы возвращаемых значений — это новая возможность появившаяся в C# 7, которая позволяет использовать не только Task в качестве возвращаемого типа асинхронных (async/await) методов, но также и любые другие типы (классы или структуры), удовлетворяющие определенным требованиям.

В то же время async/await — это способ последовательно вызвать некий набор функций внутри некоторого контекста, что является сущностью шаблона проектирования Монада. Возникает вопрос, можем ли мы использовать async/await для написания кода, который будет вести себя так же, как если бы мы использовали монады? Оказывается, что да (с некоторыми оговорками). Например, приведенный ниже код компилируется и работает:

async Task Main()
{
  foreach (var s in new[] { "1,2", "3,7,1", null, "1" })
  {
      var res = await Sum(s).GetMaybeResult();
      Console.WriteLine(res.IsNothing ? "Nothing" : res.GetValue().ToString());
  }
  // 3, 11, Nothing, Nothing
}

async Maybe<int> Sum(string input)
{
    var args = await Split(input);//Нет проверки результата
    var result = 0;
    foreach (var arg in args)
        result += await Parse(arg);//Нет проверки результата
    return result;
}

Maybe<string[]> Split(string str)
{
  var parts = str?.Split(',').Where(s=>!string.IsNullOrWhiteSpace(s)).ToArray();
  return parts == null || parts.Length < 2 ? Maybe<string[]>.Nothing() : parts;
}

Maybe<int> Parse(string str)
    => int.TryParse(str, out var result) ? result : Maybe<int>.Nothing();

Далее я объясняю, как работает этот код ...

Привет, Хабр!

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

Введение

В Haskell принято работать с эффектами как с функторами, объектами которых являются некоторые выражения, которые нам интересны в данный момент.

Когда мы видим тип выражения Maybe a, мы абстрагируемся от фактического существования некоторого a, сконцентрировав все внимание именно на этом a. Та же история с List a — множественные значения a; State s a — a, зависящая от некоторого текущего состояния; Either e a — a, которое может вернуть некоторую ошибку e.

В прошлой части расследования Роман Тимушев посоветовал связаться с Владом, что я и сделал. Влад уточнил, что меня интересует, делайны и согласился написать несколько абзацев. На следующее утро я увидел уведомление в Facebook. Это Влад нашел нового свидетеля — Александра Подхалюзина. С 2008 по 2017 он работал как тимлид над Scala plugin в IDEA и лично видел все развитие Scala-движения, но, в основном, не российскую часть.

В голове «щелкнуло» — планы меняются, это новая нить в расследовании. Обозначили время и записали часовое интервью с Александром. Информации столько, что вместить его куда либо кроме отдельной части не было вариантов. Поэтому, предупреждаю — впереди много текста.



В этой части говорим с Александром Подхалюзиным и Михаилом Муцянко. Вне программы — комментарий Ильи Сергея. Scala plugin, первые Scala-мероприятия в России, уход в Kotlin, Native на обоих языках, закат Eclipse и многое другое под катом.

5 лет назад, после поиска годного решения в RxJs, Beacon, ...etc.js, и остановившись на flyd.js и написал 4-6 проектов используя только три фичи из либы stream, on, combine. Остальное оказалось не у дел, хотелось легкости бандла. Так появился alak, первые версии до 0.3 были всего 20-30 строк и полностью заменили flyd.

Год спустя появилась версия 0.4 уже на 72 строки с паттерн матчингом и mix (аналог combine из flyd или computed из vue). Спустя три года и десятки проектов — появилось ощущение годности делится опытом и релизить 1.0.

На Хабре можно найти много публикаций, раскрывающих как теорию монад, так и практику их применения. Большинство этих статей ожидаемо про Haskell. Я не буду в n-й раз пересказывать теорию. Сегодня мы поговорим про некоторые проблемы Erlang, способы их решения с помощью монад, частичного применения функций и синтаксического сахара из erlando – классной библиотеки от команды RabbitMQ.

В крупных или микросервисных архитектурах самый важный сервис не всегда самый производительный и бывает не предназначен для хайлоада. Мы говорим о бэкенде. Он работает медленно — теряет время на обработке данных и ожидании ответа между ним и СУБД, и не масштабируется. Даже если само приложение масштабируется легко, это узкое место не масштабируется совсем. Как эту проблему решить и обеспечить высокую производительность? Как обеспечить ответ системы, когда важные источники информации молчат?



Если ваша архитектура полностью соответствует Reactive-манифесту, составные части приложения неограниченно масштабируются с возрастанием нагрузки независимо друг от друга, и выдерживают падение любого узла, — вы знаете ответ. Но если нет, то Олег Нижников (Odomontois) расскажет, как проблему масштабируемости решили в Тинькофф, построив свой безболезненный Fallback Cache на Scala, не переписывая приложение.

Примечание. В статье будет минимум кода на Scala и максимум общих принципов и идей.

Программисты, кажется, забыли реальную цель программного обеспечения — это решать реальные проблемы.

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

Независимо от того, каким путем программирование пошло с тех пор, по-прежнему существует проблема с разделением между бизнесом и разработкой программного обеспечения — или «ИНЖИНИРИНГ», как впервые назвала конференция. Если разработчики слишком сосредоточены на разработке, они могут пропустить цель программного обеспечения, которое они пишут. Они могут не видеть скрытых решений, которые не требуют никакого кода.

Эта серия интервью приурочена к ScalaConf — к первой настоящей конференции в России, полностью посвященной Scala, которая пройдет 26 ноября. Перед этим событием я взял интервью у 6 свидетелей и «апостолов» зарождения движения Scala в России. Здесь не будет обсуждения Free, Tagless Final, Monix, IO или ZIO, и «попинывания» Future. Моя цель — обсудить Scala в историческом контексте. Я записал все бородатые байки, сгонял в прошлое на 10 лет назад и собрал неактуальные, но интересные истории о языке.



Серия задумывалась в формате «Намедни» Парфенова — события, люди, явления. Я собирался найти тех, кто когда-либо организовывал митапы в России, собрать у них информацию о всем важном и интересном, отсортировать и расставить по годам. Каждое интервью начинал с того, что просил максимально точно установить год повествования. Но, интервью получились не такими как я ожидал и резать их в формате «Намедни» рука не поднялась. Поэтому серия будет рассказывать истории в формате личного расследования. Как все было, в какой очередности, как выходил на людей, и что я о них знал до интервью. Под катом — допросы и протоколы, первые проекты на Scala, первые митапы и зарождение движения.

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

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

Что объединяет «каррирование», «монады», «алгебраические типы данных»? Не только тот факт, что часть разработчиков старается обходить эти слова стороной, но еще и функциональное программирование. Под заботливым руководством Евгения Елчева мы погрузились в функциональную парадигму и почти все поняли. Не пугайтесь раньше времени, смело читайте расшифровку десятого выпуска подкаста AppsCast.

Сегодня мы представляем вашему вниманию продолжение перевода материала о вреде так называемого «функционального» программирования.

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

С другой стороны, элементы функционального стиля программирования уже проникли в промышленные языки программирования, такие как Swift и Kotlin. Разработчики этих языков прекрасно знакомы с функциональным программированием, поэтому смогли применить его «в малом», предусмотрев многие, хотя и не все, необходимые компоненты. Чем дальше — тем больше части ФП внедряются в промышленные ЯП, и тем качественнее и полнее реализуется поддержка.

Уметь программировать в функциональном стиле полезно, чтобы упрощать себе работу, и сейчас мы посмотрим, как этим воспользоваться!


Виталий Брагилевский — преподаватель ФП, теории алгоритмов и вычислений, автор книги «Haskell in Depth» и участник комитетов Haskell 2020 и наблюдательного комитета компилятора GHC.

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

Ни в коем случае этого не делайте!



Функциональное программирование полно недочётов, оно не подходит для реальных проектов. Его применение приведёт к резкому падению производительности труда. Почему это так? Давайте выясним.

▍→ Часть 2

ASP.NET Core по стандарту предлагает настраивать доступ к api с помощью атрибутов, есть возможность ограничить доступ пользователям с определенным claim, можно определять политики и привязывать к контроллерам, создавая контроллеры для разных ролей
У этой системы есть минусы, самый большой в том, что смотря на этот атрибут:

[Authorize(Roles = "Administrator")]
public class AdministrationController : Controller
{
}

Мы не получаем никакой информации о том, какими правами обладает администратор.

Благодарим автора блога Антона Екименко за его доклад

Введение

Эта заметка написана по следам конференции Wolfram Russian Technology Conference и содержит конспект доклада, с которым я выступал. Мероприятие состоялось в июне в городе Санкт-Петербурге. Учитывая то, что работаю я в квартале от места проведения конференции, я не мог не посетить это событие. В 2016 и 2017 годах я слушал доклады конференции, а в этом году выступил с докладом. Во–первых, появилась интересная (как мне кажется) тема, которую мы развиваем с Кириллом Беловым, а во-вторых, после длительного изучения законодательства РФ в части санкционной политики, на предприятии, где я тружусь появилось аж целых две лицензии Wolfram Mathematica.

Я присоединился к сообществу Erlang около 10 лет назад, посреди первой фазы хайпа. Нам говорили, что Erlang — это будущее конкурентности и параллелизма. Реализовать их на этом языке проще и быстрее всего, и вы ещё получите бесплатную распределённость. В то время будущее казалось невероятным. Виртуальная машина недавно получила поддержку SMP, но чтобы действительно использовать все процессоры, приходилось запускать на одном компьютере несколько виртуальных машин.

Я хочу поразмышлять о прошедшем десятилетии. В этой статье я расскажу о фазах хайпа в отношении Erlang, о лестнице идей в языке и о её возможном влиянии на распространение языка, о том, через какие перемены я прошёл за эти 10 лет. И в заключение поделюсь своими мыслями о том, что Erlang ещё предстоит привнести в сообщество программистов в целом.