?

Log in

No account? Create an account
dump -0f - /dev/mind
Я знаю Haskell, OCaml, GSM, эндофункторы и много других страшных слов
Языки программирования в условиях, приближенных к боевым 
4th-Nov-2009 12:26 am
После выхода второго номера журнала "Практика функционального программирования" у меня состоялась интересная переписка с неким программистом, который очень любит писать на C.

Кульминацией этой переписки стало то, что он предложил мне следующее пари: я формулирую простенькую задачу, после чего мы оба реализуем ее - он на С, я - на Haskell. После этого в условие вносятся небольшие коррективы (моделируем поведение требований в реальном мире), а мы вносим коррективы в наши программы. Результаты сравниваются по скорости исполнения, объему потребляемой памяти, количеству строк кода.

Мой оппонент изначально был поставлен в неравные условия, т.к. я мог подобрать задачу так, чтобы ее было удобно реализовывать мне, и неудобно реализовывать ему. Впрочем, я постарался выбрать задачу так, чтобы ее решение не требовало каких-то узкоспециальных знаний. Фактически, мы занимались тем, что читали из файла и обрабатывали некую сложную структуру данных. (Детальное условие я тут не привожу, чтобы не "сбивать прицел" второй половине поста).

Моя первая версия активно использовала Data.Generics и библиотечные парсеры на их основе, поэтому выиграла в размере и читаемости кода, но пролетела по объему потребляемой памяти. Впрочем, мой оппонент настолько понадеялся на мощь C, что решил не использовать библиотечный qsort, а реализовать insertion sort самостоятельно. Это самым пагубным образом сказалось на производительности (LOCs - строки кода, память - в мегабайтах, время - в секундах):


LOCs MEM max Runtime, sec
Haskell, v1 72 580 88
C++, v1 861 55 383


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

В результате я тоже решил "срезать углы", и принести красоту кода в жертву скорости. Мой же оппонент взялся за qsort, и к вторые (финальная) версии нашего кода "финишировали" с такими результатами:


LOCs MEM max Runtime, sec
Haskell, v2 169 130 8
C++, v2 950 54 5


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


К чему я все это веду?

Существует классическая статья "Haskell vs. Ada vs. C++ vs. Awk vs. ... An Experiment in Software Prototyping Productivity", написанная в 1994-м году. За 15 лет многое изменилось, и, думается, многим было бы интересно прочитать подобную статью про положение дел сегодня.

В связи с этим ищутся:
1)Условия подходящей задачи (критерии см. ниже)
2)Желающие реализовать ее на Haskell/C+/Ocaml/Java/Scala/C#/... с тем, чтобы ваш код был нещадно сравнен с другими и опубликован для всеобщего обозрения.


Q:Зачем все это делается?
A:На других посмотреть, себя показать. В частности, чтобы люди имели возможность посмотреть на решения на других языках, и составить о них какие-то мнение.

Q:Чем не устраивает The Great Language Shootout?
A:Тем, что там отдается предпочтение "быстрым и грязным" решениям, которые всячески "срезают углы". Во-первых, в таком стиле пишется дай бог чтобы 5% от всех программ, во-вторых, людям, не знающим язык X, строго противопоказано смотреть на решения на языке X в Language Shootout - останется превратное впечатление.

Q:Как будут сравниваться решения, чтобы определить победителя?
A:Никак, т.к. победителей не будет. Будут приведена определенная статистика по всем решениям, без выводов.

Q:Какой тогда стимул участвовать?
A:На других посмотреть, себя показать :)

Какой должна быть задача?
1)Не заточенной под конкретную ОС (т.е. "Реализовать компонент, встраеваемый в Word" или "плагин для libpam" - не катит)
2)Не заточенной под конкретный язык/фреймворк/... (т.е. "получить список сигнатур методов всех объектов указанной сборки .Net" - не катит)
3)Если глубокие знания в предметной области дают решающее преимущество - это fail (т.е. "реализовать DES-CBC" - не катит)
4)Чтобы она не была из категории "мне не нужно, чтобы плац был чистый, а нужно, чтобы вы задолбались" (т.е. "распарсить XLS-файл, не пользуясь библиотеками" - не катит)
5)Задача не должна требовать много времени на реализацию (если это будут человеко-недели - никто за нее не возьмется)

Какой должна быть реализация?
1)Чтобы ее было не стыдно показать другим. В частности, чтобы решение на языке X не заплевали бы как кривое и неидиоматичное другие программисты, знающие язык X.
2)Идеально было бы давать две реализации: первую с ориентиром на "красоту", "образцово-показательность" и легкость поддержки/развития кода (т.е. пишем как пример кода, который будет прилагаться к резюме :), а вторую - "грязную и быструю".
3)Т.к. библиотеки - это неотъемлимая часть силы и популярности языка, библиотеками "общего назначения" (контейнеры, парсинг, ...) пользоваться можно и нужно
4)Но! Решение, которое свелось к исключительно к нахождению и использованию какой-то (узкоспециальной) библиотеки никому не интересно и рассматриваться не будет.

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

Если у вас есть идея подходящией задачи и вы хотите ей поделится - напишите комментарий, а?
Comments 
21st-Nov-2009 11:23 am (UTC)
Из этого наброса сложно вычисляется тезис. Но попробую.

1. Функциональные языки менее распространены, чем нефункциональные. Это правда, это исторически обусловленно.
1.1. Скорость выполнения, например, просасывала по-полной императивным языкам. Но каким языкам? Она просасывала языкам типа C, которые сейчас явно не в фаворе. А те языки, которые в фаворе (Java, C#) отличаются от современных функциональных языков на какой-то эпсилон.
1.2. Уровень абстракции, быстро достигаемый с помощью функциональных языков, был не нужен в восьмидесятых годах. Тогда ещё занимались инфраструктурой, обслуживанием машин (там C рулил), а не высокоуровневой аналитикой.

2. Функциональные языки применимы только в узких областях. Нет, это неправда.
2.1. Они применимы в гораздо более широких областях, чем принято считать. Впрочем, количество проектов в этих областях у функциональных языков будет необходимо меньше, чем количество проектов в тех же областях, делаемых на императивных языках. Смотри пункт 1, почему: чисто статистически, менее распространённый язык будет меньше представлен в какой либо, выбранной наугад, области.
2.2. Функциональные языки вертикально масштабирются до самых требовательных применений. Обратим внимание: несмотря на то, что они менее распространены, во почти всех областях, где они используются, они достигают самых высоких мест по важным критериям: способности выдерживать нагрузки, способности инженеров справляться с объемом получившегося кода, etc. Это показывают примеры с Facebook, Twitter, Amazon.

3. FP никто не использует в России. Это неправда. Источники были уже приведены. Если после этого возникает вопрос, почему их так мало, то, логично, смотри пункт 1, про распространённость языка.

4. Россия — третий мир, и наиболее рутинные задачи будут спускаться сюда, в аутсорс, в существенной степени определяя рынок и используемые технологии (PHP, Java, etc). Кто это сказал? Кто здесь? Может и верно.

5. Наш проект (4+ mln $ финансирования, двадцать программистов в России) использует OCaml + Erlang в качестве основной рабочей лошади.

6. Даже если FP где-то рулит, то использовать нужно мейнстримные языки. Ну это кому как — мне интересно не соревноваться с толпой программистов на Java или C#, пишущих очередные опердени. А на более экзотических задачах, где стандартные библиотеки уже не спасают, функциональные языки имеют преимущество. Поэтому выбор — ориентироваться на мейнстрим, или ориентироваться на странные платформы — он целиком индивидуальный.

Заодно отвечу про Erlang и Scala.

"Мог быть - каким угодно" — не мог: немутабельность состояния — это существенная фича для эрланга, она идёт рука об руку с многопоточностью, поэтому императивным он быть не мог. Императивный эрланг называется Go, и сосёт.

Если Scala не рассматривать как функциональный язык, или Erlang не рассматривать как функциональный язык, мы получим, что распространённый функциональный язык всего один: Haskell.

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

Рассматривать же FP == Haskell — это слишком узко, чтобы такая точка зрения была полезной.
(Deleted comment)
21st-Nov-2009 01:43 pm (UTC)
a) 2. Функциональные языки применимы только в узких областях. Нет, это неправда.
Это - факт. Пункт 1 дает ему частичное объяснение, а не объявляет неправдой. Жизнь покажет - изменится ли этот факт. Пока - правда.

b) Примеры показывают что можно использовать, (то есть что ФЯ - вполне универсальные ЯП), а не - преимущество.

a) и b) противоречат друг другу. Применимы только в узких областях, или вполне универсальные ЯП?

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

Речь идёт о перформансе внутри эпсилона, а не о фичах.

Далее у меня годами вопрос - да где же ты, конкретный программист должен обрабатывать 30 тыс запросов в секунду?

Хрен его знает. У меня что ни проект — то highload. ipcad на гигабитных скоростях должен работать. Netli — четыреста машин в двадцати колокейшнах. Cisco — гигабитные скорости на одной машине. Теперь — десять миллионов пользователей.

Так что пишу о том, что у меня болит. У кого — такая же шняга, могут и прислушаться. Остальные свободны. Ты, например, для чего здесь всё это пишешь: доказать, что мне OCaml не нужен? Или доказать, что он не всем нужен? С последним я и не спорил никогда.

Работаешь в Yahoo, Facebook, Twitter, Amazon? А каков процент работающих в такого уровня компаниях, по сравнению с остальной программерской братией чтобы считать что такие задачи ("30 тыс запросов") - широко распространены?

В Cisco работает немногим менее сотни тысяч человек. И очень многие заняты вертикальным масштабированием.

В Cisco для того, чтобы упростить control plane, мы засунули туда, внутрь C, интерпретируемый язык — Lua. Не LISP, к сожалению — но практика показывает, что повышение уровня абстракции было жизненно необходимым.

Погодите, то есть то что я и сказал - 20 программистов против "неисчислимых толп".

Опять цифры распространённости пошли? Ну так я и говорю — толпитесь дальше. Моя личная апологетика направлена на тех, кто способен выпрыгнуть из толпы в интересные им самим ниши, и заниматься более интересным для себя делом.

Есть польза мне как разработчику от прочитанной статьи? Могу что-то применить? Какие преимущества перед выбранными нами инструментами? Сплошные нет и куча вопросов оставшимся даже не упомянутыми в статье.

В следующих номерах и эти проблемы будут разобраны. Если читателям будет интересно.

И вся эта экзотика - не нужна.

Не обязательна. Но возможна и работоспособна.
(Deleted comment)
21st-Nov-2009 05:41 pm (UTC)
Поскольку меня тут упомянули, отвечу.

>>Есть и ещё, есть. ;)
>>Нас много. ;)
>Да, читал наезд на Ваш, Сергей(thesz) стиль работы. И был удивлен, эти много сосредоточились в одной компании :) Среди тех "20ти" программистов и gaperton'а.

Функциональных программистов в том эпическом обсуждении с нашей работы было: я, да potan. Моделирующих программистов четыре, с нами был ещё garrrrr (или как его там), да t_h_e_d_i_p. В обсуждении не участвовало ещё несколько моделирующих программистов из отдела Гусарова.

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

Наезд был не на мой стиль работы, а на мою презентацию результатов и мои открытия, связанные с быстродействием системы garrrrr сотоварищи.

С объяснениям покончено, переходим к объяснениям.

>Пытаюсь понять логику твоего и других выбора. А вдруг и мне пригодится?

Мой выбор был прост. Я хотел проводить эксперименты как можно быстрее, и не задумываться, является ли плохой результат работы программы моей ошибкой в программировании или ошибкой в самом алгоритме. Иными словами, мне нужно было, чтобы "скомпилировалось, значит, написано правильно".

Я писал про это дело пост, но найти не могу. :(

В процессе поиска я перебрал несколько вариантов метапрогарммирования и попробовал несколько языков программирования. До Хаскеля я добрался только на третий просмотр всего списка языков программирования.
(Deleted comment)
21st-Nov-2009 01:20 pm (UTC) - Re: ...continue (2/2)
В императиве известна давно под названием - передаем/возращаем данные по ссылке или по значению (даже в dBase с 1Сами можно указать). Не вижу причин почему ее нельзя встраивать в "бейсик".

Проблему shallow copy/deep copy откидываем как несущественную? Проблему с изменением переданных данных изнутри стека вызовов — тоже?

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

Вот и выбираю — у нас кроме OCaml и Erlang есть ещё Haskell, JavaScript, Perl, C, C++, Python и PHP.

Более того, на C у меня в опен сорсе больше программ (ipcad, asn1c), чем на FP. И писал я на нём десятки и сотни тысяч строк в год. Этот опыт не отменяет того, что на FP, в случае, когда я его выбираю, я более продуктивен.

И придерись, пожалуйста к когда я его выбираю.
21st-Nov-2009 04:12 pm (UTC) - Re: ...continue (2/2)
"И писал я на нём ... сотни тысяч строк в год."

1000 строк в день, каждый рабочий день, в течении года? Это ж два ~ апача (на глаз) в год написать можно.
22nd-Nov-2009 07:42 am (UTC) - Re: ...continue (2/2)
Да, так то и был типа такой апач. Продали за 188 миллионов долларов фирме Akamai.

И не 1000 строк в день, а 1500-2000, раз в два дня.
24th-Nov-2009 07:30 am (UTC) - Re: ...continue (2/2)
Сдается мне, что человеку, который может писать по 1500-2000 строк откомментированного и отлаженного C-шного кода раз в два дня, совершенно фиолетово, на чем писать.

Живьем я правда таких монстров не видел, только в Интернете.
18th-Aug-2011 12:10 pm (UTC) - Re: ...continue (2/2)
Anonymous
> Сдается мне, что...совершенно фиолетово, на чем писать.
Неправильно сдается.
This page was loaded Jul 21st 2019, 6:19 am GMT.