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

В прошлой части расследования Роман Тимушев посоветовал связаться с Владом, что я и сделал. Влад уточнил, что меня интересует, делайны и согласился написать несколько абзацев. На следующее утро я увидел уведомление в 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 ещё предстоит привнести в сообщество программистов в целом.

«Функции высшего порядка» — это одна из тех фраз, которыми часто разбрасываются. Но редко кто может остановиться и объяснить, что это такое. Возможно, вы уже знаете, что называют функциями высшего порядка. Но как мы используем их в реальных проектах? Когда и почему они бывают полезны? Можем ли мы с их помощью манипулировать DOM? Или люди, которые используют эти функции, просто хвастаются? Быть может, они бессмысленно усложняют код?

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

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

Недостаток один — высокий порог входа. Пытаясь разобраться в ФП, я столкнулся с огромным количеством теории, функторами, монадами, теорией категорий и алгебраическими типами данных. А как применять ФП на практике, было неясно. Кроме того, примеры приводились на незнакомых мне языках — хаскеле и скале.

Тогда я решил разобраться в ФП самого начала. Разобрался и рассказал на codefest о том, что ФП — это на самом деле просто, что мы уже им пользуемся в Swift и можем пользоваться еще эффективнее.

Привет, Хабр. Меня зовут Максим, я iOS-разработчик в компании FINCH. Сегодня я покажу вам некоторые практики использования функционального программирования, которые мы наработали у себя в отделе.

Согласно Elm Architecture, вся логика приложения сконцентрирована в одном месте. Это довольно простой и удобный подход, но с ростом приложения можно увидеть функцию update длиной 700 строк, Msg с сотней конструкторов и Model, не умещающуюся в экран.

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

"…те, кто не прочь поглазеть на любителя прилюдно свалять дурака, пусть понаблюдают, как я доказываю, что Java и Visual Basic – близнецы, разлученные при рождении, а С++ им даже не дальний родственник."

Брюс Мак-Кинни “Крепкий орешек Visual Basic”

Введение

Постоянный интерес к подходам функционального программирования в настоящее время приводит к тому, что традиционные языки программирования активно обзаводятся функциональными средствами. И, хотя чистые функциональные языки остаются пока не слишком популярными, функциональные возможности прочно обосновались в таких языках, как С++, Java, JavaScript, Python и др. Язык VBA уже многие годы пользуется заслуженной популярностью у довольно многочисленной аудитории пользователей Microsoft Office, однако этот язык практически не содержит функциональных средств.

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

* благодаря его отсутствию

Продолжение статьи про Phoenix Live View. Сегодня я опишу базовую конфигурацию для комфортной работы с технологией и создам новое приложение.