Обновить
15.08

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

От Lisp до Haskell

Сначала показывать
Порог рейтинга
Уровень сложности

EWD: Процессы Подстановки

Время на прочтение17 мин
Охват и читатели9.5K
Эдсгер Дейкстра
Привет, Хабр! Представляю вашему вниманию перевод статьи Substitution Processes (1962 год) авторства Эдсгера Дейкстры. Разделение на параграфы не оригинальное.


Введение


Машина определяет (по самой своей структуре) язык, а именно: свой язык ввода — и напротив, семантическое определение языка задаёт машину, способную понимать его. Другими словами, машина и язык — это две стороны одной и той же медали. Я собираюсь описать такую медаль. Я оставляю на вас решение того, какой же из этих двух аспектов предмета моего разговора, на ваш взгляд, самый важный, так как сам считаю этот выбор довольно смешным. Язык, наброски которого я собираюсь вам предоставить, является непозволительно трудным для человека, а машина, которую я собираюсь описать, является порочно неэффективной.

Поэтому, если моя ментальная конструкция, тем не менее, имеет право на существование, его оправдание должно быть найдено в других качествах. Найти их в моей машине можно, по моему мнению и суждению, по крайней мере в её исключительной простоте и элегантности, в единообразии способов, которыми она выполняет довольно разные (на первый взгляд) операции; оправдание моего языка — это его ясность и необычайно высокая степень двусмысленности, вытекающая из строгой последовательной интерпретации и явного указания в программе выполняемых операций, хотя обычно выполнение всех операций подразумевается (и из этого проистекают некоторые недоразумения). Если кто-то захочет, он может считать мои машину и язык придуманными в образовательных целях.
Читать дальше →

RxSwift: немного о share(), replay(), shareReplayLatestWhileConnected() и других классных операторах

Время на прочтение3 мин
Охват и читатели15K
Я уже писал про Publish, Connect и RefCount в RxSwift. Для того, чтобы лучше раскрыть тему, представляю вашему вниманию перевод другой замечательной статьи, про различия между такими операторами, как share(), replay(), replayAll(), shareReplay(), publish() и shareReplayLatestWhileConnected().

Частая ошибка, которую совершают новички, взявшиеся за освоение Rx — это непонимание того, что цепочка операторов на Observable выполняется заново с каждым новым подписчиком:

let results = query.rx.text
    .flatMapLatest { query in
        networkRequestAPI(query)
    }
results.subscribe(...)   // один запрос в сеть
results.subscribe(...)   // другой запрос

Мы имеем несколько подписчиков на один-единственный Observable, но мы не хотим, чтобы его код исполнялся с каждым новым Subscriber'ом. Для этого в RxSwift имеется несколько операторов. Вот резюмирующая табличка, описывающая каждый из них:

image
1 — ретранслирует произведенных до подписки элементов не больше, чем bufferSize.
2 — ретранслирует 1 элемент, произведенный до подписки, до тех пор, пока существует хотя бы один подписчик.

Читать дальше →

OCaml и RESTful JSON API с использованием Eliom

Время на прочтение9 мин
Охват и читатели4.1K
Привет, Хабр! Представляю вашему вниманию перевод руководства RESTful JSON API using Eliom.

В этом руководстве рассказывается, как создать простой, но полный REST API с использованием JSON в качестве формата сериализации.
Читать дальше →

Некоторые приемы функционального программирования в Python

Время на прочтение2 мин
Охват и читатели6.5K

Привет, Хабр!
В этой статье я хотел бы рассказать о том, что пришло в Python из функциональных языков программирования. Заинтересовавшихся прошу под кат.

Читать дальше →

О качестве требований в ИТ проектах, начистоту (с позиции команды разработки). Часть 3

Время на прочтение4 мин
Охват и читатели9K
С частью 1 можно ознакомиться, перейдя по ссылке
С частью 2 можно ознакомиться, перейдя по ссылке

Использование спецификаций требований в управлении проектом


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

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

Но, естественно есть погрешности и процедура – процедуре рознь, поэтому, для более точного расчета можно использовать коэффициенты сложности для реализуемых объектов. Например, «сложная форма» — 1,5; «обычная форма» — 1; «простая форма» — 0,5. Для каждого типа элемента подбираем свою линейку значений коэффициентов. Полученные таким образом данные можно занести в электронную таблицу и сбить итоговые затраты в человеко\днях или человеко\часах (как Вам удобнее) по подсистемам и проекту в целом.
Читать дальше →

Liscript — web REPL: поцелуи, велосипеды и экскаваторы

Время на прочтение5 мин
Охват и читатели4.1K


Некоторое время назад я написал интерпретатор лиспоподобного языка, который назвал Liscript. Опубликовал несколько статей на Хабре, посвященных особенностям реализации ядра, TCO, GUI, REPL-ботов и т.п. Недавно добавил web-интерфейс REPL-у (ссылка в конце статьи).

При чем здесь поцелуи и экскаваторы? Думаю, большинству известны такие аббревиатуры, как KISS (keep it simple stupid — делай это проще, дурачок), YAGNI (You ain't gonna need it — Вам это не понадобится), а также высказывания людей разной степени великости про архитектурных астронавтов, «все должно быть сделано так просто, насколько возможно, но не проще», и т.п.

Допустим, перед вами стоит задача — выкопать яму. Какие есть варианты решения? Взять лопату и выкопать самому — дешево и сердито, но долго и возможно неоптимально (зависит от вашего уровня владения лопатой и размеров ямы). Отдать на аутсорс таджикам (не будем рассматривать здесь этот вариант, хотя я должен был его упомянуть). Взять экскаватор — быстро и эффективно, но затратно: бензин/аренда, плюс не факт, что он проедет в вашу садовую калитку, значит надо сносить/восстанавливать забор и т.д. Также, необходимо определиться с моделью (порой из 100500 вариантов), а если вы будете управлять им самостоятельно, надо разобраться во всех его рычагах и педалях.

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

В общем, про выбор инструментов под задачи, и конкретные (подозреваю, что спорные) решения, которые я выбирал в процессе реализации проекта, под катом.
Читать дальше →

О качестве требований в ИТ проектах, начистоту (с позиции команды разработки). Часть 2

Время на прочтение8 мин
Охват и читатели17K
С частью 1 можно ознакомиться, перейдя по ссылке

Рекомендации по проектированию спецификаций требований с примерами


То, о чем не говорят, каждый понимает по-своему

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

Готовим читателей к знакомству со спецификациями


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

Пример обзора документа:



Для лучшего восприятия контекста разрабатываемой системы, помимо разделов, отобранных нами в структуру документа — как обязательные, я стараюсь включить в текст информацию о целях, которые должны быть достигнуты в результате разработки целевого продукта или его составного модуля. Разработчики все-таки должны осознавать, чего же желает заказчик получить на выходе проекта. Для описания этого раздела подойдут формализованные Потребности заказчика. Похожий раздел есть в большинстве стандартов, например в ГОСТ-34.602-89 [4] он называется «назначение и цели создания (развития) системы».
Читать дальше →

Прагматичное функциональное программирование

Время на прочтение5 мин
Охват и читатели16K

Движение к функциональному программированию началось всерьез примерно десятилетие назад. Мы видели как такие языки как Scala, Clojure и F# стали привлекать внимание. Это движение было больше чем просто обычное восхищение «О, круто, новый язык!». Было что-то действительно побуждающее это движение — или мы так думали.

Читать дальше →

О качестве требований в ИТ проектах, начистоту (с позиции команды разработки). Часть 1

Время на прочтение8 мин
Охват и читатели20K
По мотивам моей статьи, изданной ранее…

Вступление


Получить бы медаль, а уж с обратной ее стороной найдем, что делать.
(Георгий Александров)

В подавляющем большинстве работ, посвященных управлению требованиями, которые мне довелось читать [1], [2], [3] и другие, авторы хороводят вокруг заказчика, акцентируя основное внимание читателей на том, как максимально эффективно организовать работу именно с ним. Ну и конечно, львиная доля труда обычно посвящена вопросам преобразования собранной информации в некие проектные решения, моделирующие разрабатываемую систему, а также оформление их со спецэффектами, бантиками и рюшами. Разумеется это все важно и я ни в коем случае не хочу умолить значение этих аспектов формирования требований, но есть еще и обратная сторона. Ведь дальше требования должны попадать непосредственно в “цех” по производству программного обеспечения. И именно там они, до самого рождения целевого продукта, останутся основным сводом законов и правил, по которым он будет зарождаться и являться миру. Этот факт уже сам по себе определяет важность того, насколько точно требования должны соответствовать интересам специалистов, призванных воплотить их в конечном продукте.

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

Всё познаётся в сравнении, или реализация одной простенькой задачи на python и tcl

Время на прочтение8 мин
Охват и читатели11K
В силу исторических причин, у нас в конторе, используется старенькая АТС Panasonic TDA200. И, как известно, журнал звонков она выводит в последовательный порт, для чтения данных из которого, на сервере использовалась одна программулька. У этого ПО есть ряд ограничений, делающий его использование неудобным (размер лог-файла, размер БД) и дабы побороть эти недостатки и в силу природной лени (чтобы избежать постоянной очистки лога и БД вручную) было решено набыдлокодить что-то своё. А так как, уже давно, на глаза попадается слово «python» да и пытливый ум периодически просыпается, то решено было данную задачу реализовать на этом языке и попутно на, хорошо мне знакомом, tcl. Ну а результатами решил поделиться с обществом. Да, сразу замечу, что задача решена и сервис доведён до «промышленной» эксплуатации. Для хранения данных используется СУБД MariaDB (оно уже было), в качестве хост-системы CentOS 7.
Читать дальше →

10 шагов по решению задач в программировании

Время на прочтение8 мин
Охват и читатели97K


Перевод статьи Валинды Чен.

Это сборник советов для разработчиков-новичков, которые смотрят на пустой экран и не знают, с чего начать. Нередко можно услышать от молодых разработчиков, работающих над решением каких-то задач в программировании, что они не уверены, за что нужно хвататься. Ты понимаешь саму задачу, логику, основы синтаксиса и так далее. Если ты видишь чей-то код, или тебе кто-то помогает, то можно всё сделать самому. Но бывает, что ты не уверен в своих силах, или поначалу тебе трудно реализовать свои мысли в коде, несмотря на то, что ты знаешь синтаксис и логику. Под катом — несколько советов по решению этой проблемы, которые помогут вам в повседневной работе.
Читать дальше →

ICFP Contest 2017 — проверка на прочность для настоящих разработчиков

Время на прочтение5 мин
Охват и читатели7.8K
ICFPC — ежегодное соревнование для программистов. Оно проходит в онлайне и длится 72 часа. ICFPC 2017 начнётся в пятницу 4 августа в 12:00 (UTC) и закончится в понедельник.

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


Мониторинг акторов в Akka.Net, но на F#

Время на прочтение15 мин
Охват и читатели6.5K
Сразу скажу, хаба для F# на хабре нет, поэтому пишу в C#.

Для тех кто не знаком с F#, но знаком с C#, рекомендую наисвежайшую статью от Microsoft.
Она поможет Вам испытывать меньше WTF моментов при прочтении, т.к. моя статья не туториал к синтаксису.


Контекст задачи


Есть сервис, написанный на Akka.NET, он вываливает в разные текстовые логи кучу инфы. Отдел эксплуатации грепает эти логи, жарит по ним регекспами, чтобы узнать о кол-ве ошибок (бизнесовых и не очень), о кол-ве входящих в сервис сообщений и кол-ве исходящих. Далее эта информация заливается в ElasticDB, InfluxDB и показывается в Grafana и Kibana в разных срезах и агрегациях.

Звучит сложно, да и парсить текстовые логи сервиса, который генерит несколько десятков ГБ текстового мусора в день — занятие неблагодарное. Поэтому встала задача — сервис должен быть способен поднять ендпоинт, который можно дёрнуть и получить сразу всю инфу о нём.

Решать задачу будем так:

  1. Напишем доменную модель для метрик
  2. Замапим доменную модель метрик на реализацию App.Metrics и поднимем апишечку
  3. Сделаем структурированный доменный логгер, который натянем на внутренний логгер Akka
  4. Сделаем обёртку для функциональных акторов, которая спрячет работу с метриками и логгером
  5. Соберём всё вместе и запустим
Читать дальше →

Ближайшие события

Чёрная Лямбда ефрейтора Волкова: новое направление и гранты на летнюю школу

Время на прочтение4 мин
Охват и читатели4.8K


Не далее чем в июле прошла очередная школа GoTo. В этот раз мы решили внести некоторое разнообразие в стандартный набор Ардуин, Питонов, и прочих, и случился Хаскелль. Небольшое отделение из 6 юношей (кусочек нашего общего взвода в 60 человек) бодро промаршивало по $\lambda$-исчислению, основам синтаксиса, прошло посвящение в ФП написанием факториала, посворачивало списки, научилось словосочетанию "параметрически полиморфная функция высшего порядка" и присущему этому пониманию типов и тайпклассов под предводительством ефрейтора Волкова.


А ещё у нас были элементы инфобеза, криптовалюты, React Native, nix, и, конечно, git.


И мы начали писать книгу про Haskell.


В общем, получилось задорно.


(Под катом картинки участников, лямбды, илосос, анонс нового направления и гранты)

Читать дальше →

Scala коллекции: секреты и трюки

Время на прочтение28 мин
Охват и читатели36K

Представляю вашему вниманию перевод статьи Павла Фатина Scala Collections Tips and Tricks. Павел работает в JetBrains и занимается разработкой Scala плагина для IntelliJ IDEA. Далее, повествование идет от лица автора.


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


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


Этот список вдохновлен моими попытками разработать практичные инспекции для Scala коллекций, для Scala плагина IntelliJ. Сейчас мы внедряем эти инспекции, так что, используя Scala плагин в IDEA, вы автоматически выигрываете от статического анализа кода.


Тем не менее, эти рецепты ценны сами по себе. Они могут помочь вам углубить понимание стандартной библиотеки коллекций Scala и сделать ваш код быстрее и выразительнее.


Обновление:
Если вы испытываете тягу к приключениям,
вы можете узнать, как помочь в развитии IntelliJ плагина для Scala и попробовать свои силы в реализации, подобрав подходящую инспекцию.

Читать дальше →

Создание движка для блога с помощью Phoenix и Elixir / Часть 10. Тестирование каналов

Время на прочтение9 мин
Охват и читатели3.1K


От переводчика: «Elixir и Phoenix — прекрасный пример того, куда движется современная веб-разработка. Уже сейчас эти инструменты предоставляют качественный доступ к технологиям реального времени для веб-приложений. Сайты с повышенной интерактивностью, многопользовательские браузерные игры, микросервисы — те направления, в которых данные технологии сослужат хорошую службу. Далее представлен перевод серии из 11 статей, подробно описывающих аспекты разработки на фреймворке Феникс казалось бы такой тривиальной вещи, как блоговый движок. Но не спешите кукситься, будет действительно интересно, особенно если статьи побудят вас обратить внимание на Эликсир либо стать его последователями.»


В этой части мы научимся тестировать каналы.

Читать дальше →

Почему изменения в новом Phoenix 1.3 так важны

Время на прочтение8 мин
Охват и читатели6.7K


Phoenix Framework всегда был классным. Но он никогда не был таким классным, как с новым релизом 1.3 (который сейчас находится в стадии RC2).


Произошло много значительных изменений. Крис МакКорд написал полный путеводитель по изменениям. Так же доступна его речь с LonestarElixir, где он подробно рассказывает про ключевые моменты. Вдохновленный его трудами, в своей статье я постараюсь рассказать вам про самые важные изменения в проекте Phoenix.


Давайте начнем!


Перевод выполнен самим автором оригинальной статьи Никитой Соболевым.

Читать дальше →

Создание движка для блога с помощью Phoenix и Elixir / Часть 9. Каналы

Время на прочтение16 мин
Охват и читатели4.9K


От переводчика: «Elixir и Phoenix — прекрасный пример того, куда движется современная веб-разработка. Уже сейчас эти инструменты предоставляют качественный доступ к технологиям реального времени для веб-приложений. Сайты с повышенной интерактивностью, многопользовательские браузерные игры, микросервисы — те направления, в которых данные технологии сослужат хорошую службу. Далее представлен перевод серии из 11 статей, подробно описывающих аспекты разработки на фреймворке Феникс казалось бы такой тривиальной вещи, как блоговый движок. Но не спешите кукситься, будет действительно интересно, особенно если статьи побудят вас обратить внимание на Эликсир либо стать его последователями.

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

Читать дальше →

Как использовать implicit'ы в Scala и сохранить рассудок

Время на прочтение8 мин
Охват и читатели31K

image


Scala богата выразительными средствами, за что ее и не любят опытные программисты на классических ООП-языках. Неявные параметры и преобразования — одна из самых спорных фич языка. Слово "неявные", уже как-бы намекает на что-то неочевидное и сбивающее с толку. Тем не менее, если с ними подружиться, implicit'ы открывают широкие возможности: от сокращения объема кода до возможности многие проверки делать в compile-time.


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


Читать дальше →

Игры на Scheme(Lisp) в среде DrRacket

Время на прочтение4 мин
Охват и читатели8.1K
Для запуска программ, приведённых в статье, можно использовать DrRacket. Для начала рассмотрим связь конечного автомата и игрового процесса. Объект управления в игре можно представить в виде конечного автомата. Рассмотрим программу, моделирующую светофор. Этот пример был описан в предыдущей статье.

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

image
Читать дальше →