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

Я не понимаю причины существования бесконечных споров вокруг Объектно-ориентированного (ООП) и Функционального (ФП) программирования. Кажется, что такого рода вещи находятся за пределами человеческого понимая, и о них можно спорить бесконечно. Много лет занимаясь исследованием языков программирования, я увидел четкий ответ, и зачастую я нахожу бессмысленным обсуждение этих вопросов.

Если кратко, то как ООП, так и ФП неэффективны, если доходить в их использовании до крайности. Крайностью в ООП считается идея о том что “все что угодно является объектом” (чистое ОП). Крайностью для ФП можно рассматривать чистые функциональные языки программирования.

Известно, что задача определения того, истинна ли некоторая функция Integer -> Bool хотя бы для одного числа вычислительно неразрешима. Однако, нечто, на первый взгляд кажущееся как раз таким оракулом (а именно, функцией (Integer -> Bool) -> Maybe Integer) будет описано в этой статье.

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

data Nat = Zero | Succ Nat deriving (Eq, Ord, Show)

Другими словами, натуральное число — это либо ноль, либо некоторое натуральное число, увеличенное на единицу (Succ от слова successor).

Также, для удобства, определим основные операции (сложение, умножение, конвертация из Integer) над числами в таком представлении:

instance Num Nat where
    Zero + y = y
    Succ x + y = Succ (x + y)

    Zero * y = Zero
    Succ x * y = y + (x * y)

    fromInteger 0 = Zero
    fromInteger n = Succ (fromInteger (n-1))

Статья устарела, актуальную информацию ищите на сайте Warp9'а



Существует множество реактивных и около-реактивных библиотек для создания графического интерфейса на js: Angular, Knockout, React, RxJS… Спрашивается, зачем писать еще одну. Оказывается, во всех них, помимо фатального недостатка, есть еще несколько.

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

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

Теория «Черного лебедя»

Автор теории Нассим Николас Талеб, описавший ее своей книге «Чёрный лебедь. Под знаком непредсказуемости». Теория рассматривает труднопрогнозируемые и редкие события, которые несут за собой значительные последствия. Процессы реального мира не возможно описать с точки зрение одной лишь математики, и в доказательство этому рассмотрим один простой пример.

Часто, при создании достаточно сложных приложений на JavaScript наступает тот момент, когда становиться совершенно непонятно почему приложение перестало работать как надо, или наоборот вдруг заработало. Cвязей между элементами приложения становится так много, что уследить за ними даже с хорошими дебаггером очень трудно. И вот диллема: с одной стороны есть хорошо известная методика создания приложений на JS, столь привычная и глубоко описанная, что недостатков мы уже как бы и не замечаем. С другой стороны есть масса библиотек предлагающих нам перейти на другую сторону попробовать что-то новое. К таким библиотекам относиться и Bacon.js, предоставляя реализацию FRP на JavaScript.

Предыдущая статья цикла Язык программирования J. Взгляд любителя. Часть 3. Массивы

1. Коробки

Мы уже столкнулись с тем, что существительное в J — это массив. Даже над одиночными константными значениями допустимы векторные операции. В совокупности все это составляет удобную векторную гомогенную среду программирования.

Однако, очевидно, что у массивов есть и свои ограничения. В связи с тем, что в J по умолчанию только прямоугольные массивы, то и нет возможности стандартными средствами создавать т.н. ступенчатые (jagged) массивы. Кроме того, для списков, состоящих из разнородных элементов, массивы также не подходят.

Предыдущая статья цикла Язык программирования J. Взгляд любителя. Часть 2. Тацитное программирование

«Я не думаю, что он нам подходит. Я рассказал ему, чем мы занимаемся, и он не стал спорить. Он просто слушал.»
Кен Айверсон после одного из собеседований

1. Массивы

J – язык для обработки массивов. Для создания массивов в J есть множество способов. Например:

• «$» — этот глагол возвращает массив, размерность которого указывается в левом операнде, а содержимое — в правом. Создадим массив заданной размерности, все элементы которого одинаковы:
  
  

  	3 $ 1   NB. создаем вектор с тремя элементами, каждый из которых = 1
  1 1 1
  	2 3 $ 2 NB. создаем матрицу из 2 строк и 3 столбцов, все элементы которой = 2
  2 2 2
  2 2 2
  

  
  

Первый мой топик на Хабре будет посвящен моим научным исследованиям, которые связаны с методами построения алгоритмов генерации тестовых заданий для организации контроля знаний обучаемых.

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

Использование языков программирования для описания алгоритмов генерации не поддается критике и имеет ряд преимуществ относительно имеющихся методов, так как программный код и возможности применяемого языка позволяют описывать задания для широкого класса дисциплин. Единственный недостаток — отсутствие навыков программирования у большинства преподавателей, особенно, у гуманитариев.

Предыдущая статья цикла Язык программирования J. Взгляд любителя. Часть 1. Введение

Вопрос: Если функции изменяют данные, а операторы изменяют функции, тогда кто изменяет операторы?
Ответ: Кен Айверсон
Chirag Pathak

В J используется идея тацитного (от слова «tacit», неявный) программирования, не требующего явного упоминания аргументов определяемой функции (программы). Работа в тацитном подходе происходит, как правило, с массивами данных, а не с отдельными их элементами.
Интересно заметить, что тацитное программирование было открыто Бэкусом еще до APL и реализовано им в языке FP. Среди современных языков, поддерживающих такой подход, (кроме, естественно, J) можно назвать Форт и другие конкатенативные языки, а также Haskell (за счет point-free подхода).

1. Глаголы

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

	neg =: -

Дейкстра: А как вы запишите более сложное выражение? Например, сумму всех элементов матрицы, которые равны сумме индексов соответствующих строк и столбцов.
Айверсон: + + / (M = ?1 ^(o)+ ?1)M//
(Кеннет Айверсон — создатель языков APL и J)

1. Быстрый старт

Перед тем как APL получил свое название, он назывался «нотация Айверсона». Однако Кен считал, что название должно звучать просто как «Нотация». И в самом деле, мы же не говорим «трава Бога», мы говорим просто «трава».
Paul Berry

Отличительными особенностями языка программирования J можно назвать:

• векторная арифметика
• предельная лаконичность
• обширная стандартная библиотека, предназначенная в частности для статистической обработки данных
• наличие в стандартной библиотеке функций для рисования 2d графиков и 3d поверхностей, а также примитивов для создания графического интерфейса
• подробнейшая и разнообразнейшая документация и примеры

Можно сказать, что J находится в той же нише, что и Matlab и R. Но есть одно «но» — синтаксис языка.
Приведем один из самых распространенных учебных примеров всех введений и туториалов J:

	mean =: +/%#

В данном примере определяется новая функция (на языке J это называется «глаголом») «mean», которая рассчитывает среднее значение в массиве чисел.

Доброго вечера, дорогие Хабровчане. Мы продолжаем изучение Erlang для самых маленьких.

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

В этой главе мы поднимемся на следующую ступень и рассмотрим модули и функции.

Хаскель отличает себя от большинства функциональных языков тем, что имеет глубокие культурные корни из области математики и информатики, которые дают обманчивое впечатление, что Хаскель плохо подходит для решения практических задач. Однако, чем больше вы знаете Хаскель, тем больше вы цените то, что теория часто является наиболее практическим решением многих общих проблем программирования. Этой статьёй хочется подчеркнуть эту точку зрения тем, что мы смешаем имеющиеся в наличии теоретические основы и создадим чистую пользовательскую систему потоков.

Добрый день, дорогие хабражители.

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

Я давно обещался написать статью о том, как себя показал Haskell в реальных задачах в продакте.

Для тех, кто не уследил — его в начале 2012 пролоббировали и с энтузиазмом начали внедрять программисты в Селектеле. Тогда же я обещал опубликовать отчёт о том, насколько «это всё» можно использовать.

Продакт в коммерческом проекте — это не в маленькая песочница «для себя», не академический эксперимент в области Computer Science. Это бесконечная борьба за «линию партии», когда вокруг ад, ужас и погибель, а оно всё равно должно работать. Int64 в XML-RPC кодируется строкой (потому что int'ы в XML-RPC signed int32), openssl при чтении нескольких сертификатов из файла читает только первый из них, в bool надо писать либо «1», либо «0», но иногда — «2», ибо только так придумали закодировать третий режим — и т.д. и т.п. В этих условиях требования к языку постепенно перерастают в требования к его экосистеме, инфраструктуре, готовности адаптироваться к реальному миру.

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

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

Начнём с потребительских свойств.

Рич Хикки произноситит классные, дающие пищу для размышления выступления. Считается, почти всем, если не поголовно, программистам надо их услышать и увидеть. Если вы не интересуетесь Clojure, лучше смотреть с конца.

• Are We There Yet? – 2009 -размышления о том, правилен ли текущий подход к реализации ООП. Обсуждается много вопросов о проектировании Clojure.

После просмотра курса Programming Languages и прочтения Functional JavaScript захотелось повторить все эти крутые штуки в python. Часть вещей получилось сделать красиво и легко, остальное вышло страшным и непригодным для использования.

Статья включает в себя:

• немного непонятных слов;
• каррирование;
• pattern matching;
• рекурсия (включая хвостовую).

Статья рассчитана на python 3.3+.

14 сентября 2013 года в петербургском офисе JetBrains состоялся бесплатный однодневный тренинг по языку Scala.

Вел тренинг Александр Alefas Подхалюзин, разработчик плагина поддержки Scala в IntelliJ IDEA. За день он провел вводный практический курс по Scala, занятия шли с 12:00 до 19:00. Курс был предназначен для начинающих (или желающих начать), однако все участники должны были иметь опыт разработки на Java.

Тренинг мы устроили для того, чтобы напомнить, что для Java есть альтернатива. Разработчику подсознательно хочется, чтобы его подтолкнули в новом направлении: развиваться-то надо, а времени нет, да и вообще спать хочется. Так что тренинг должен был стать катализатором желания развиваться у тех, кто пришел, а заодно помочь решить, годится ли Scala для решения их задач.

На самом деле, в каком-то смысле, этот вопрос не имеет смысл в 2010х, когда большинство (или большинство самых распространенных) языков являются языками многих парадигм. Зачем себя ограничивать только функциональным программированием? Возможно, кому-то ответ покажется очевидным, но если появляются такие статьи как "Десять причин не использовать статически типизированный функциональный язык программирования", то придется дискутировать и объяснять противную точку зрения. «Десять причин...» основаны на иронии и, похоже, автор подразумевает, что упомянутые недостатки даже не требуют обсуждения, а только ироничных замечаний. Но это не так, давайте пройдемся по этим десяти причинам.

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

Линзы

Ваш билет к элегантному коду — это библиотека линз (lens).