Полтора года назад адепты функционального программирования основали сообщество RuHaskell и с тех пор периодически собираются, и проводят митапы. Ну как периодически — уже два раза собирались. Мы тут, в «Лаборатории Касперского», вообще очень поддерживаем это начинание. Во-первых, потому что это интересно, во-вторых, потому что мы используем Haskell в процессе разработки наших решений, а в-третьих, потому что некоторые участники сообщества у нас работают. А потому мы решили собрать третий митап этого сообщества на нашей территории. 18 августа все заинтересованные могут прийти в наш московский офис (Ленинградское шоссе, д.39А, стр.2), послушать умных людей, обсудить Haskell, поделиться опытом, позадавать вопросы и пообщаться. Разумеется, предварительно следует зарегистрироваться вот на этой страничке.
Рубрика «функциональное программирование» - 33
Митап Haskell-программистов в «Лаборатории Касперского» (в смысле — ждем)
2016-08-15 в 11:16, admin, рубрики: elm, haskell, Блог компании «Лаборатория Касперского», встреча, лаборатория касперского, Программирование, функциональное программированиеElixir: Как выглядит ООП в функциональном языке?
2016-08-15 в 11:09, admin, рубрики: Elixir, Erlang/OTP, WAT, ооп, Программирование, функциональное программированиеВ последнее время участились статьи и обсуждения на тему прощания с ООП и поиски смысла, который Алан Кэй изначально вкладывал в это понятие.
I made up the term “object-oriented”, and I can tell you I didn't have C++ in mind
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.
I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to focus on the lesser idea. The big idea is “messaging”.
The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be.
Late binding allows ideas learned late in project development to be reformulated into the project with exponentially less effort than traditional early binding systems (C, C++, Java, etc.)
I’m not against types, but I don’t know of any type systems that aren’t a complete pain, so I still like dynamic typing.
В связи с этими обсуждениями, часто всплывает мысль о том, что Erlang/Elixir очень хорошо удовлетворяют критериям, которые Кэй предъявлял к понятию «объектно-ориентированный». Но далеко не все знакомы с этими языками, поэтому возникает непонимание как функциональные языки могут быть более объектно-ориентированными, чем популярные C++, Java, C#.
В этой статье я хочу на простом примере с exercism.io показать как выглядит ООП на Elixir.
В конце концов, вы должны быть в состоянии:
- Добавить имя школьника в класс
- Получить список всех школьников, обучающихся в классе
- Получить отсортированный список всех учащихся во всех классах. Классы должны быть отсортированы по возрастанию (1, 2, 3 и т.д.), а имена школьников — по алфавиту.
История языков программирования: как Haskell стал стандартом функционального программирования
2016-08-11 в 15:48, admin, рубрики: haskell, история языков программирования, параллельное программирование, функциональное программирование, метки: история языков программирования
Теоретические основы императивного программирования были заложены ещё в 30-х годах XX века Аланом Тьюрингом и Джоном фон Нейманом. Теория, положенная в основу функционального подхода, формировалась в 20-х и 30-х годах. В числе разработчиков математических основ функционального программирования — Мозес Шёнфинкель (Германия и Россия) и Хаскелл Карри (Англия), а также Алонзо Чёрч (США). Шёнфинкель и Карри заложили основы комбинаторной логики, а Чёрч является создателем лямбда-исчисления.
Функциональное программирование как раз основано на идеях из комбинаторной логики и лямбда-исчисления.
Но теория так и оставалась теорией, пока в начале 50-х прошлого века Джон МакКарти не разработал язык Lisp (1958), который стал первым почти функциональным языком программирования. На протяжении многих лет у Lisp не было конкурентов. Позднее появились функциональные языки программирования APL (1964), ISWIM (1966) и FP (1977), которые не получили столь широкого распространения.
Со временем Lisp перестал удовлетворять некоторым требованиям разработчиков программ, особенно с ростом объема и сложности программного кода. Читать полностью »
Elixir: Развёртывание приложений с помощью Edeliver
2016-08-09 в 13:14, admin, рубрики: configuration, deployment, deployment tools, Elixir, Erlang/OTP, functional programming, функциональное программирование
Мы уже обсуждали сборку и развёртывание приложений Elixir(перев: с помощью exrm): как осуществлять миграции поверх релиза или как работать с переменными среды. Пришло время открыть для себя ещё один инструмент, который поможет развёртывать Elixir приложения.
Практика развёртывания Elixir приложений и дальнейшее отслеживание их работы на нодах с помощью Exrm позволяет нам чувствовать себя гораздо увереннее в вопросах управления релизами в production. Однако возникает следующий вопрос: как управлять самим процессом развёртывания? Конечно, мы можем воспользоваться Capistrano, особенно если в мир Elixir мы пришли из Rails. Но посмотрим на цитату из Edeliver README:
edeliver основан на доставке и предоставляет bash-скрипт для сборки и развёртывания Elixir и Erlang приложений, а так же позволяет совершать "горячее" обновление кода.
Пытаться организовать весь процесс развёртывания вручную — это жёсткая головная боль с кучей повторяющегося кода. А вот использование Edeliver для развёртывания оказалось очень простым с первой же попытки! В конце концов, весь процесс развёртывания уместился в один меленький bash-скрипт:
#!/bin/bash -ex
BRANCH=${1:-master};
mix edeliver build release --branch=BRANCH --verbose
mix edeliver deploy release to production --verbose
mix edeliver start production --verbose
mix edeliver migrate production up --verbose
Скорее всего Вам придётся подкрутить этот скрипт под собственные нужды. Мы используем его только для развёртывания в production, но Вы так же можете использовать его и для staging развёртываний. Описание того, как всё это работает — под катом.
Конечные автоматы в среде динамического моделирования SimInTech. Часть 2
2016-08-08 в 14:32, admin, рубрики: scada, Анализ и проектирование систем, Графические оболочки, математическое моделирование, программирование контроллеров, Промышленное программирование, разработка программного обеспечения, функциональное программированиеВ первой части мы показали как создать алгоритм работы на основе «конечных автоматов» в SimInTech и использовать его совместно с «классическими» алгоритмами в виде функционально блочных диаграмм.
Во второй части мы покажем как создать вложенные и параллельно работающие конечные автоматы и осуществлять обмен данными между ними.
Читать полностью »
Скоро ICFPC 2016
2016-08-02 в 2:26, admin, рубрики: haskell, ocaml, соревнования по программированию, Спортивное программирование, функциональное программирование19 серия культового соревнования начнётся в пятницу, 5 августа, в 0:00 UTC.
ICFP Programming Contest — международное соревнование по программированию, проводимое ежегодно летом с 1998 года. Результаты соревнования объявляются на Международной конференции по функциональному программированию. (с) Wikipedia
JavaScript в 2016 году: функциональное программирование пришло всерьез и надолго
2016-08-01 в 8:33, admin, рубрики: angular, haskell, javascript, React, redux, Блог компании Voximplant, будущее снова здесь, философия программирования, функциональное программированиеВ 2015 году вы могли заметить перемены в способе разработки приложений на JavaScript. Разработчики уходят от непредсказуемой архитектуры с мутабельным состоянием в сторону более предсказуемой иммутабельной архитектуры приложений.
С такими фреймворками как Backbone, было принято синхронизировать сами данные и представление данных – для этого приходилось вручную подписываться на нужные события dom. Такой способ был подвержен ошибкам и вынуждал использовать слишком много типового кода. Пришел Angular и исправил это с помощью автоматизированного двустороннего биндинга.
Но сейчас все движется в другом направлении.
Читать полностью »
Маслобойка
2016-07-30 в 18:42, admin, рубрики: ооп, Программирование, Разработка веб-сайтов, функциональное программирование, метки: fp, oop, progressТы слышал про парня, который попрощался с OOП?
О нет. Ещё один? Что же он сказал?
Он описал все обещания OOП, и как ни одно из них на самом деле не было исполнено, и что все возможности ООП обходятся дороже, чем они реально стоят, и функциональное программирование лучше, и ...
Ох. Да, я слышал всё это раньше...
Таким образом, OOП окончательно умерло, и мы можем двигаться дальше.
Двигаться дальше к чему?
Ты чего? К следующему технологическому прорыву, конечно!
А, к этому… И что там у нас на очереди?
Elixir: Регистрируем процессы — практическое руководство
2016-07-28 в 9:39, admin, рубрики: Elixir, erlang, Erlang/OTP, functional programming, otp, конкурентное программирование, параллельное программирование, функциональное программирование
Процессы в Elixir
(ну и в Erlang
конечно же) идентифицируются с помощью уникального идентификатора процесса — pid.
Мы используем их, чтобы взаимодействовать с процессами. Сообщения посылаются как бы в pid
, а виртуальная машина сама заботится о доставке этих сообщений в правильный процесс.
Иногда, впрочем, чрезмерное доверие к pid
может приводить к значительным проблемам.
К примеру, мы можем хранить pid
уже мёртвого процесса, или мы можем использовать Supervisor
, который абстрагирует создание процессов от нас, поэтому мы даже не знаем, какой у них pid
(пер: а ещё Supervisor
можете перезапустить упавший процесс с другим pid
, и мы об этом не узнаем никак).
Давайте создадим простое приложение и посмотрим: с какими проблемами мы можем столкнуться и как мы эти проблемы будем решать.
Elixir: начинаем работу с Plug
2016-07-25 в 7:37, admin, рубрики: Elixir, Erlang/OTP, functional programming, otp, phoenix, функциональное программирование
В мире Elixir
, Plug
представляет собой спецификацию, позволяющую различным фреймворкам общаться с различными web-серверами, работающими в Erlang VM
.
Если вы знакомы с Ruby
, то можете провести аналогию с Rack
: Plug
пытается решать те же проблемы, но только другим способом. Понимание основ работы Plug
позволит лучше разобраться как с работой Phoenix
, так и других web-фреймворков, созданных на языке Elixir
.