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

Предыдущая статья цикла Язык программирования 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).

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

Про автора

Я разработчик и архитектор британской не софтверной компании. Имею 20 летний опыт в различных областях от высоко-уровневых UX/HCI до низко-уровневых реализаций баз данных.
Несмотря на то что я использую C# в своей повседневной работе, я писал промышленный код на многих языках, мои любимые Smalltalk, Python и совсем недавно F# (поэтому я и создал этот сайт).

Разглагольствования по поводу того чего я не понимаю

Вам надоела вся эта шумиха вокруг функциональных языков? Мне тоже! Я выскажу по этому поводу несколько причин почему разумные люди, такие как мы с вами, должны держаться подальше от этого.

Немного поясню: когда я говорю «статически типизированный функциональный язык программирования», я подразумеваю языки, которые поддерживают вывод типов по-умолчанию и прочее. На практике это означает Haskell и семейство языков ML (включая OCaml и F#).

Предисловие

Когда я начал изучать Хаскель, я был почти сразу поражён. Для начала, нырнув с головой в актуальные рабочие проекты, открыл, что большинство настоящих библиотек используют языковые расширения, присутствующие только в GHC (Glasgow Haskell Compiler). Это меня покоробило слегка, прежде всего потому, кто захочет использовать язык настолько немощный, что будет необходимо использовать расширения, присутствующие лишь у одного поставщика. Ведь так?
Хорошо, я решился снова это осилить и узнать всё об этих расширениях, и я вывел три горячих топика для общества Хаскеля, которые решали похожие проблемы: Обобщённые Алгебраические Типы Данных, Семьи Типов и Функциональные Зависимости. Пытаясь найти ресурсы, которые обучают о них, я смог найти только статьи, описывающие, что это такое, и как их использовать. Но никто, на самом деле, не объяснял зачем они нужны!.. Поэтому я решил написать эту статью, используя дружественный пример, пытаясь объяснить зачем всё-таки нужны Семьи Типов.



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

Мы собираемся использовать Хаскель для того, что бы представить ограниченную (и даже несколько упрощённую, да простят меня фанаты) часть мира покемонов.

В прошлом году на Хабре уже была очень развёрнутая статья в двух частях о декораторах. Цель этой новой статьи — cut to the chase и сразу заняться интересными, осмысленными примерами, чтобы успеть затем разобраться в примерах ещё более мудрёных, чем в предыдущих статьях.
Целевая аудитория — программисты, уже знакомые (например по C#) с функциями высшего порядка и с замыканиями, но привыкшие, что аннотации у функций — это «метаинформация», проявляющаяся только при рефлексии. Особенность Питона, сразу же бросающаяся в глаза таким программистам — то, что присутствие декоратора перед объявлением функции позволяет изменить поведение этой функции:



Как это работает?

Пары и списки

В предыдущих частях мы научились задавать новые типы данных, определять функции над ними и доказывать их корректность с помощью распространенных тактик. Настало время определить некоторые структуры данных и функции высших порядков (далее ФВП) над ними.

Внимание: перед тем как читать текст ниже, вы уже должны иметь представление о том, что такое монады. Если это не так, то прежде прочитайте вот этот пост!

Перед нами функция half:


И мы можем применить её несколько раз:

half . half $ 8
=> 2

Всё работает как и ожидалось. Но вот вы решили, что хорошо бы иметь лог того, что происходит с этой функцией:

half x = (x `div` 2, "Я только что располовинил  " ++ (show x) ++ "!")

Что ж, отлично. Но что будет если вы теперь захотите применить half несколько раз?

half . half $ 8

Вот то, что мы хотели бы, чтобы происходило:


Спойлер: автоматически так не сделается. Придётся всё расписывать ручками:

finalValue = (val2, log1 ++ log2)
    where (val1, log1) = half 8
          (val2, log2) = half val1

Фу! Это ни капли не похоже на лаконичное

half . half $ 8

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

Предисловие

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

Хотелось бы остановиться и посмотреть на развитие языков программирования с точки зрения развития пользовательских типов данных (ПТД).
Сразу хочу оговориться, под пользователями понимаются программисты, как люди, пишущие код на этих языках. Ну, и те, кто этот код сопровождает или просто читает.

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

Пользователи желают иметь примерно такие типы данных

Пользователи хотели иметь возможность составлять данные так, как они сами того хотят. Хотели, хотят, и наверняка будут хотеть. Всё больше, всё разнообразней и сильнее.
Именно поэтому полезно проследить за развитием пользовательских типов данных в программах и языках программирования.