LINUX.ORG.RU
Форум — Development  

ЛОР-конкурс: LISP vs. Everything


0

0

Дорогие друзья!

За несколько лет идея превосходства LISP (и функциональных языков вообще) над императивными языками стала настоящим феноменом ЛОРа.

Каждый раз эта тема, возникнув в рамках обсуждения какой-либо новости, приводит к жарким, невероятно интересным дискуссиям. С обеих сторон звучат вполне убедительные и красноречивые доводы. Рассматривается как технологическое, так и экономическое превосходство языков и технологий. В контексте одной из недавних новостей ("50 лет языку LISP", http://www.linux.org.ru/view-message.jsp?msgid=3184185) прозвучала идея наконец поставить точку в историческом противостоянии при помощи практического эксперимента, а именно - конкурса разработчиков.

Формат конкурса представляется таким. Выдвигаются три команды (например, LISP Nerds, Java Monkeys и C/C++ Jerks), каждая из которых должна быть представлена двумя составами. Размер состава - два-три человека. Командам предлагаются задачи по следующим восьми категориям:

1. Системное программирование;
2. Бизнес-приложения;
3. Веб-приложения;
4. Анализ текстов, компиляция и интерпретация;
5. Искусственный интеллект;
6. HPC-вычисления;
7. Компьютерные игры;
8. Desktop-приложения.

Список категорий отражает реальные задачи современного мира информационных технологий; детализация списка и подробные ТЗ последуют, обсуждение списка приветствуется.
Задачи выполняется первыми составами каждой команды. Затем проводится изменение ТЗ (ощутимое, но не кардинальное), и изменения реализуются вторым составом при условии неучастия второго состава в первом раунде. Т.е. цель второго раунда - показать, насколько возможно сопровождение программного продукта при смене команды разработчиков.
Результаты обоих раундов каждого этапа оцениваются жюри и сообществом по нескольким критериям: время, затраченное на решение; качество кода; качество продукта и соответствие требованиям; управляемость проектом, лёгкость (или сложность) поддержки и рефакторинга.
Сразу стоит отметить, что задачи будут представлять собой реальные (но сильно упрощённые) примеры задач из жизни. Упрощённые - потому что надо отдавать себе отчёт в том, что участники, скорее всего, будут весьма занятыми людьми, и их время надо уважать.

Хочется понять, вызывает ли эта идея интерес ЛОРовцев как таковой. Заинтересованным в участии (и в организации) буду благодарен за их мнения по поводу затеи. Скорее всего, это будет классический проект "Just for fun", хотя идеи насчёт организации фонда денежного приза (за счёт спонсоров, например) приветствуются. С организационной точки зрения стоит отметить необходимость площадок для развёртывания и тестирования; понадобятся также репозитории исходных текстов (SVN, GIT).

Приглашаю делиться идеями насчёт формулировки задач. Черновые формулировки уже составлены, но очень хотелось бы, чтобы от конкурса была реальная польза для сообщества, т.е. можно было брать в качестве задач bounties или просто нерешённые вопросы значимых opensource-проектов.

Отдельное спасибо зарегистрированным коллегам за освещение проекта в разделе форума Talks.

anonymous
← CERN: Java equals and sometimes outperforms C++ in many benchmarks.
Emacs Code Browser →
  1 2 →
Ответ на: комментарий от anonymous

ALGOL 68 Re: ЛОР-конкурс: LISP vs. Everything

http://www.rosettacode.org/wiki/Life_in_two_dimensions#ALGOL_68

http://www.csail.mit.edu/timeline/timeline.php?query=event&id=93

http://archive.computerhistory.org/resources/text/algol/algol_bulletin/A26/P2.. .

http://vak.ru/lib/exe/fetch.php/book/gost/pdf/gost-27974-88.pdf

http://vak.ru/lib/exe/fetch.php/book/gost/pdf/gost-27975-88.pdf

Doug Ross wrote: """Ross's efforts to remove the word "ref" from Algol X, to make it "object-oriented" (as AED was) were not understood ("...for Algol Y, maybe"). A mere shift was required. AED-0's LOC only was required for procedure-name arguments of a procedure call -- making AED procedures "first-class" objects inside procedure bodies (which was all that was required to build compilers well!) -- to use the current term. But also, AED's variables always had the type of their object value. (Message-passing of today's OO'tation is not essential to Being OO! Having Operators OF a type for Operations ON objects of that type, and assigning Variables TO objects of their declared type, not values TO variables -- that's what matters.)

References: Ross, D.T., "Features Essential for a Workable Algol X," ALGOL Bulletin, No. 26, August 1967, pp. 6-12, and ACM SIGPLAN Notices, Vol.2, No.11, November 1967. """

anonymous
()

готов присоединиться к комманде хаскелистов, пару задач в нагрузку могу решить на C++ и Tcl (но это мне куда менее интересно)

жду чёткого ТЗ

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

>готов присоединиться к комманде хаскелистов, пару задач в нагрузку могу решить на C++ и Tcl (но это мне куда менее интересно)

Итого за Haskell уже трое вызвались (включая меня). Пока рекорд. К чему бы это? Наверное Haskell подходит для всех перечисленных пунктов?

imp ★★
()
Ответ на: комментарий от imp

>Итого за Haskell уже трое вызвались (включая меня). Пока рекорд. К чему бы это? Наверное Haskell подходит для всех перечисленных пунктов?

а всё оттого, что:

"Haskell - лучший императивный язык в мире" (с) SPJ

jtootf ★★★★★
()
Ответ на: комментарий от naryl

>Каков минимальный размер команды? Боюсь даже четырёх D-программеров на ЛОРе не найти

я могу парочку не с ЛОРа привести, думаю им будет интересен подобный квест

jtootf ★★★★★
()
Ответ на: комментарий от Nagwal

В принципе могу даже задачку предложить, из реальной жизни, на прошлой работе пытались сделать (я в написании конкретно кода участвовал мало, но задачка любопытная). Есть производство (у нас была медицинская лаюоратория), есть некое формальное описание технического процесса (у нас были методики проведения лабораторного исследования) содержащее в себе информацию о последовательности типов рабочих мест и операций над обьектом, которые необходимо произвести. Задача программы - построить оптимальный маршрут образца по производству, исходя из данных о загрузке рабочих мест, экономических показателях стоимости проведения операции на конкретном рабочем месте, расписании его работы, наличии необходимых расходников итд... Список учитываемых показателей надо уточнаять в ТЗ. Задача может быть как в реализации маршрутизатора, так и в дальнейшем создании на его основе системы имитационного моделирования производства с прогнозированием показателей исходя из планируемой загрузки.

Если что мыло для связи: nagakhl гав-гав gmail.com

Nagwal ★★★★
()
Ответ на: комментарий от Nagwal

> В принципе могу даже задачку предложить, из реальной жизни, на прошлой работе пытались сделать (я в написании конкретно кода участвовал мало, но задачка любопытная). Есть производство (у нас была медицинская лаюоратория), есть некое формальное описание технического процесса (у нас были методики проведения лабораторного исследования) содержащее в себе информацию о последовательности типов рабочих мест и операций над обьектом, которые необходимо произвести. Задача программы - построить оптимальный маршрут образца по производству, исходя из данных о загрузке рабочих мест, экономических показателях стоимости проведения операции на конкретном рабочем месте, расписании его работы, наличии необходимых расходников итд... Список учитываемых показателей надо уточнаять в ТЗ. Задача может быть как в реализации маршрутизатора, так и в дальнейшем создании на его основе системы имитационного моделирования производства с прогнозированием показателей исходя из планируемой загрузки.

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

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

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

Nagwal ★★★★
()

Идея интересная, но боюсь, что ничего показать или доказать не удастся. Задача будет маленькой по объёму. А маленькие программы можно писать на чём попало. По-моему, разница будет видна, если попробовать разработать большой проект. Тогда лисперы или хаскеллисты напишут DSL и всех обскачут.

А так - могу за Жабку поучаствовать. Я уже 7 лет ЗП получаю за то, что на ней пишу. Хотя сейчас учу и болеть буду за Haskell. :-)

pitekantrop ★★★
()
Ответ на: комментарий от pitekantrop

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

pitekantrop ★★★
()
Ответ на: комментарий от pitekantrop

>По-моему, разница будет видна, если попробовать разработать большой проект. Тогда лисперы или хаскеллисты напишут DSL и всех обскачут

А кто мешает джавистам разработать грамотную библиотеку для работы с предметной областью задачи и писать дальше на ее основе?? ИМХО подход более вменяемый чем разрабатывать новый DSL, да и по производительности програмистского труда примерно то-же самое получается.

Nagwal ★★★★
()
Ответ на: комментарий от Nagwal

> ИМХО подход более вменяемый чем разрабатывать новый DSL, да и по производительности програмистского труда примерно то-же самое получается.

А ты знаешь Лисп, и можешь адекватно оценить сложность создания DSL на нём? Думаю, тебя просто пугает этот термин. :)

pitekantrop ★★★
()
Ответ на: комментарий от Nagwal

> А кто мешает джавистам разработать грамотную библиотеку для работы с предметной областью задачи и писать дальше на ее основе?? ИМХО подход более вменяемый чем разрабатывать новый DSL,

Под DSL всегда есть та самая грамотная библиотека. "Проект языка - это проект библиотеки" (c) фольклор Bell Labs. "И наоборот" (c) А.Кениг.

tailgunner ★★★★★
()
Ответ на: комментарий от Nagwal

>Ну так конкретный алгоритм в конце-концов оказывается важнее средств реализации практически в любой задаче.

Согласен. Однако реализация алгоритма может существенно отличаться в зависимости от выбранного ЯП. Разные языки программирования могут иметь различную степень выразительности и предоставлять отличающиеся по уровню абстракции и функциональности средства. Да и масштабируемость тоже будет различной. Была как-то задача из области графов. Объем кода прототипа на питоне и конечной реализации на C++ различался в разы при одинаковой функциональности (не в пользу плюсов, естественно:)). Однако с реальными задачами, для графов с числом вершин и ребер порядка нескольких миллионов, реализация на питоне не справлялась.

SSN
()
Ответ на: комментарий от Nagwal

Re^2: ЛОР-конкурс: LISP vs. Everything

>>По-моему, разница будет видна, если попробовать разработать большой проект. Тогда лисперы или хаскеллисты напишут DSL и всех обскачут

> А кто мешает джавистам разработать грамотную библиотеку для работы с предметной областью задачи и писать дальше на ее основе?

Сама жаба и мешает: уж слишком она невыразительна.

gaa ★★
()
Ответ на: комментарий от jtootf

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

den73 ★★★★★
()

Если задача не слишком объёмна, могу на PLT Scheme попробовать, уж очень он мне нравится.

Legioner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 →
← CERN: Java equals and sometimes outperforms C++ in many benchmarks.
Development
Emacs Code Browser →