практика функционального программирования журнал
Практика функционального программирования
Вы только что изучили Nemerle и мечтаете зарабатывать с его помощью деньги? Побеждайте, и получайте денежный приз.
Вы жаждете личной славы? Победа в конкурсе — прекрасный способ заявить о себе со страниц нашего журнала.
Вы давно искали повод показать, что никакие Erlang и Haskell в подметки не годятся старому доброму C++? Побеждайте — и у вас появится аргумент для будущих споров, способный сразить любого.
Подробнее о целях проведения конкурса
Мы предлагаем нашим читателям вместе с нами сравнить подходы к решению задач в рамках разных парадигм программирования и соответствующих им инструментальных средств.
Как же будут сравниваться подходы и инструментальные средства? С помощью объективного и субъективного оценивания решений нескольких практических задач.
В качестве объективных показателей мы хотим использовать не только измеримые параметры самого решения (количество строк кода, скорость работы и так далее), но и сведения о производственном процессе (например, время, затраченное вами на разработку и на тестирование).
Кроме того, хотелось бы оценить целый ряд сложно поддающихся формализации свойств: красоту и лаконичность кода, его читаемость, легкость в поддержке и сопровождении. Вместо введения каких-то формальных критериев мы хотим поручить оценку этих параметров компетентному жюри.
Естественно, мы понимаем, что нет двух одинаковых программистов, и персональные качества участников будут скрытым фактором, оказывающим решающее влияние на результат. Однако мы считаем, что невозможность измерить что-то в точности — это совсем не повод отказаться от измерений вообще.
Может быть, в результате станет очевидным преимущество функционального подхода. Может быть — императивного. Мы уверены, что это — не главное. Мы рассчитываем в первую очередь на то, что из накопленных данных можно будет извлечь интересные закономерности (например, тенденцию к потреблению памяти разными языками, скорость работы, etc), и опубликуем подробный анализ в ближайшем номере.
Мы хотим построить эксперимент так, чтобы он был лишен существенных недостатков, присущих другим подобным исследованиям (см. исторический обзор ниже): задачи будут «практические», а не «академические», они будут подобраны так, чтобы не давать очевидного преимущества той или иной парадигме программирования. Для этого мы собрали около тридцати заданий разных уровней сложности и попросили 18 программистов-профессионалов (в разных парадигмах программирования) ранжировать задачи по интересности и адекватности в качестве конкурсных задач. Уверены, что использование такого «разношёрстного» жюри для оценки задач — лучшее, что мы можем сделать для того, чтобы исключить «уклон» в сторону конкретного языка или парадигмы. Для того чтобы исключить влияние случайных факторов на выбор членов жюри, мы взяли для конкурса не одну, а две самых популярных задачи.
Подавляющее большинство существующих исследований подобного рода проведены в англоязычных странах Мы хотим, чтобы этот эксперимент позволил нам с вами получить сведения о навыках и подходах уникальной аудитории — русскоязычных программистов-практиков начала двадцать первого века.
Чтобы позволить другим исследователям сделать самостоятельные выводы, мы опубликуем все корректные варианты решений и весь массив накопленных статистических данных.
Условия проведения конкурса
Конкурс стартует в момент выхода в свет этого (третьего) номера журнала и заканчивается 1 марта 2010 года. Результаты исследования будут опубликованы в пятом номере. Любые изменения в графике будут загодя опубликованы на этой странице, а также в LJ-сообществе fprog.
В конкурсе могут участвовать все желающие.
Как будут оцениваться решения? Даже с учётом предположения, что присылать вы будете только работающие программы, встаёт проблема оценки решений. Что лучше: короткий код, работающий медленно, или грузный, но работающий мгновенно? А может быть, лучше всего тот код, который структурирован для расширяемости? Конечно, все эти метрики мы попробуем проанализировать интегрально, для разных задач и для разных языков. Но задачу определения победителя это не облегчит! Мы думаем, что заставив членов разношёрстного жюри ранжировать присланные варианты по «качеству решения», а затем скомбинировав их ответы, мы сможем на основании субъективных метрик получить лучшее приближение к объективности, на которое мы только можем рассчитывать в рамках подобного конкурса.
Учтите, что жюри будет интегрально оценивать элегантность, профессиональность и читаемость решения, а скорость исполнения и использование памяти — в разумных пределах игнорировать.
Победители конкурса получат специальное упоминание на страницах журнала, а также ценные призы:
Кроме того, все победители получат по экземпляру книг «Практика работы на языке Haskell» и «Справочник по языку Haskell» Р. Душкина с дарственной подписью автора.
Требования к оформлению решений
Представьте, что условие задачи — это сформулированные заказчиком требования к проекту. Или даже к первой фазе проекта — то есть, в дальнейшем ожидается развитие и модификация кода.
Заказчик ожидает получить от вас не только готовое решение, но и исходные тексты программы, которые он будет тщательно просматривать. Соответственно, от вас ожидается профессиональное исполнение и промышленное качество кода. В частности, заказчик наверняка будет ожидать:
Вы можете использовать сторонние свободно доступные библиотеки для всех вспомогательных задач в рамках вашего решения. Не используйте сторонние библиотеки для реализации основных алгоритмов задачи. Если ваше решение включает в себя свободно доступный код других авторов — укажите это.
Сделайте акцент на корректности генерируемых вашим решением выходных файлов. Вы можете рассчитывать на то, что входные данные будут в точности соответствовать спецификации, но вы должны быть уверены, что в рамках спецификации вы корректно обрабатываете все возможные варианты.
Не занимайтесь избыточной оптимизацией — присылайте нам первое работающее решение. Если до окончания конкурса вы решите доработать свою программу — присылайте нам новый вариант, указав в описании время, затраченное на оптимизацию.
По возможности, работайте сами — результаты коллективной работы будут вносить искажения в наши измерения.
Разместите в архиве файл README, описывающий решение в формате:
Пример архива с оформленным решением: gantt-jwizard-01.zip.
Условия задач
В рамках каждой задачи существуют градации сложности, называемые уровнями. Только от вас зависит, сколько задач и в каком объёме вы будете решать. Мы постарались сделать, чтобы решение обеих задач в минимальном объёме («уровень 1») заняло у вас суммарно не более 4-10 часов.
Экскурс в историю
Мы, конечно же, не первые, кто пытается сравнивать языки программирования.
В этой спорной и потенциально «взрывоопасной» области существует известное количество правильно поставленных экспериментов, которые на статистически значимом материале уверенно демонстрируют преимущество тех или иных инструментов, подходов, или языков программирования в тех или иных отношениях.
Одной из первых работ, поставившей своей целью сравнить сразу несколько принципиально различных языков, можно считать [Hudak94vs.ada]. В этом классическом исследовании приведены данные, из которых следует, что скриптовые и функциональные языки имеют где-то 2-3 кратный выигрыш во времени программирования и объеме кода по сравнению с программами на C++ и Ada. С другой стороны, программы на C++ и Ada оказываются в 2-3 раза быстрее программ на других языках программирования. Впрочем, авторы справедливо посчитали, что имевшиеся в их распоряжении данные не составляли репрезентативной выборки (мало участников исследования, большая разница в степени владения языками) и ограничились в своих выводах осторожными общими фразами.
Шесть лет спустя в исследовании Лутца Прехельта ([Prechelt_anempirical]) было рассмотрено семь языков (C, C++, Java, Perl, Python, Rexx и Tcl), которые использовались для написания простой программы, преобразующей номер телефона в набор слов по определенным правилам. В исследовании принимали участие добровольцы, всего было накоплено около 80 вариантов решений. В результате автор пришел, в частности, к таким выводам:
В то же время, многие попытки подобных сравнений дают в результате весьма однобокий взгляд на проблему. Типичными недостатками в этом случае являются:
Мы решительно настроены не допустить подобных «проколов» и постараемся сделать все возможное, чтобы оценки были сделаны максимально объективно, а результаты анализа не были ангажированы.
Список литературы
Этот документ был получен из L A TEX при помощи H E V E A
© 2009—2011 «Практика функционального программирования» ISSN 2075-8456
Практика функционального программирования
Прошу оценить правильность направления поиска идеального языка программирования
Виды элементов классов:
Каскадные лексические анализаторы времени компиляции для использования национальных языков при программировании
Компилятор языка использует стандартные ключевые слова на английском языке, но включает опцию для каскадированного включения в таблицу лексем синонимов на национальных языках. Для первоначального включения синонимов используется опция языка компилирования, файлы национальных синонимов могут включать ссылки (опция include) на файлы синонимов
Суперкомпиляция (supervising compilation) — техника преобразования программ, основанная на построении полной и самодостаточной модели программы.
В статье описываются основные идеи и методы суперкомпиляции на примере работающего суперкомпилятора SC Mini для простейшего чисто функционального языка.
Supercompilation (supervising compilation) is a program transformation technique based upon constructing a self-sufficient model of the program.
The paper describes the main ideas and methods of supercompilation through a series of examples
performed by the simple supercompiler SC Mini.
В данной статье определяется проблемная область, задачи которой успешно решаются при помощи продолжений, анализируются традиционные методы решения таких задач и рассматриваются несколько практических примеров с эффективным использованием продолжений.
This article defines a subject area whose problems can be conveniently solved with the use of continuations; we analyze the traditional methods of solving these problems and consider a few practical examples with efficient use of continuations.
Ответ на статью Максима Сохацкого (опубликованную несколькими страницами ранее), в котором делается попытка показать, что написание прототипа LDAP-сервера на языке Си ничуть не сложнее, чем на Эрланге. Проводится cравнение полученных решений.
This is a response to the preceding Maxim Sokhatsky’s article. We’re aiming to show that creating a LDAP server prototype in C is not any more complex than writing it in Erlang. We compare the resulting C and Erlang solutions.
Статья про то, как с нуля быстро сделать прототип сервера, отвечающего по LDAP протоколу стандартному почтовому клиенту. В качестве основного инструмента весьма к месту был выбран Erlang.
This is an article about a rapidly-prototyped LDAP server capable of answering to a default Mail client. Erlang is the language of our choice.
В данной статье мы рассмотрим пример использования среды Mathematica для быстрого прототипирования простого алгоритма обнаружения движения. Кроме общих приёмов работы с Mathematica, мы познакомим читателя с некоторыми понятиями из области машинного зрения, цифровой обработки изображении и сигналов. При разработке мы применим некоторые из подходов функционального программирования, поддерживаемых Mathematica.
In this article, we will use Mathematica to develop a prototype of a simple motion detection algorithm. We will introduce the basics of using Mathematica environment and use this exercise to illustrate some basic concepts from the fields of machine vision, digital image processing and signal processing. We will be using some of the functional programming capabilities provided by Mathematica.
Веб-фреймворк Circumflex — одна из сравнительно недавних разработок на Scala, и, на взгляд автора, гораздо менее известная, чем она того заслуживает. В статье описываются отличия Circumflex от других веб-фреймворков, применение языковых средств Scala для создания необходимых фреймворку DSL, подход к структурированию Scala-проектов, применяемый разработчиками фреймворка, и другие его интересные особенности.
Circumflex is a relatively new player among Scala web frameworks; it appears to be much less popular than it deserves, from author’s point of view. This article outlines the differences between Circumflex and other web frameworks, its employment of Scala language features to build useful DSLs, its clever approach to structuring of Scala code and other interesting features.
Знакомство с языком Рефал полезно программисту хотя бы потому, что этот функциональный язык не похож ни на один из других — среди них он занимает особое место и по возрасту, и по происхождению, и по назначению, и по стилю. Достойно сожаления то что, несмотря на свои качества, язык не очень популярен.
Статья знакомит читателя с Рефалом. Язык так прост, что его описание почти целиком вмещается в статью — за исключением стандартных функций, которых тоже немного. Простота сама по себе — положительное качество, но читатель убедится, что оно не единственно.
Помимо описания самого Рефала, представлен взгляд автора на место, достоинства и слабые стороны языка.
Knowing the Refal language is useful to a programmer, if for nothing else than for the language’s uniqueness — with respect to its age, its origin, its intended purpose, and style. It is regrettable that, in spite of its qualities, the language is not very popular.
This article gives an introduction to Refal.