Каким должен быть язык программирования? Анализ и критика Описание языка Компилятор
Отечественные разработки Cтатьи на компьютерные темы Компьютерный юмор Новости и прочее

Почему Хаскелл так мало используется в отрасли?

Недавно Bugspy недавно задал интересный вопрос на Stack Overflow :

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

Джефф Этвуд, соучредитель Stack Overflow, закрыл тогда этот вопрос. К сожалению, Марк Гравелл решил отредактировать мой ответ и удалить половину моих комментариев, поэтому обсуждение больше не имеет смысла. Однако мой ответ будет интересен тем, кто ставит на свои деньги в Хаскелл, поэтому я его повторю здесь.

Первая точка интереса — ответ Нормана Рэмси, который был написан с его точки зрения как академический. Норман объясняет, почему он считает, что крупные институты уже имели «большую пользу» от Хаскелла: «Не говорите об этом Credit Suisse или Standard Chartered, двум банкам, которые широко использовали Хаскелл. И не говорите Peerium или Galois или любому другому успешному стартапу, который использует Хаскелл. Не говорите никому из коммерческих пользователей функционального программирования. И особенно не говорите их клиентам!»

Ссылаясь на Credit Suisse и Standard Chartered, крупные банки с большими именами, они надеятся, что заставят людей поверить, что эти институты серьезно инвестированы в Хаскелл. Но нет. На самом деле, количество разработчиков Хаскелла, работающих полный рабочий день в Credit Suisse, уже давно упало до нуля, кроме одного, сбежавшего в Standard Chartered. Это крошечная доля процента от общего объема усилий по развитию в этих институтах и не представляет собой «большое использование Хаскелла» даже в воображении.

Цитирование же CUFP (Commercial Users of Functional Programming) также вводит в заблуждение. Ведь CUFP — это, прежде всего, конференция Хаскелла, почти полностью состоящая из ученых да студентов, ни у одного из которых нет клиентов.

Норман Рэмси продолжает:

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

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

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

В той же теме на Stack Overflow Дон Стюарт утверждал, что «Хаскелл, во всяком случае, более широко используется, чем большинство языков функционального программирования», а затем цитировал распространенность Хаскелл среди делегатов CUFP в качестве доказательства. Конечно, это не может быть дальше от истины. У Mathematica есть миллионы пользователей и десятки коммерческих библиотек. F# Hub имеет 21,228 зарегистрированных членов, а F# имеет несколько коммерческих библиотек (например, WebSharper, CoherentPDF, F# для визуализации и F# для чисел). Напротив, у Haskell-Cafe всего 3,339 подписчиков и у Хаскелла никогда не было коммерческих библиотек.

Промышленность очень разнообразна, и она часто вознаграждает за риск с использованием новых технологий, поскольку это может дать вам конкурентное преимущество. Мы регулярно рискуем с помощью таких технологий, как OCaml и F#. Если вы считаете это правильным, то это может принести дивиденды. Если вы ошибётесь, вы пойдете по пути Red Nucleus (один из многих покойных стартапов Хаскелла). Мы в 2007 году решили внести разнообразие , и мне поставили задачу найти для нас другие языки функционального программирования. Я внимательно изучил Хаскелл и принял осознанное решение не приближаться к нему по следующим причинам:

  • Отсутствие убедительных примеров. После долгих поисков я нашел только одну программу «Power Serious» Дуга Макилроя, которую я нашел убедительной, но это просто академическое любопытство.
  • Отсутствие настоящих историй успеха. После небольшого рытья я был в ужасе, обнаружив, что почти все «истории успеха», перечисленные на странице «Haskell in Industry», были подделками. Anygma может приступить к проекту в будущем, но не намерена писать его на Хаскелле. У Ansemond (это на самом деле настоящая компания-разработчик программного обеспечения) был продукт, но (согласно их блогу) в их продукте Хаскелла не было. Antiope не перечислил никаких продуктов вообще, не говоря уже о написанных на Хаскелле. Bluespec рекламировали свой продукт, но отзывы их клиентов были получены от «Elvis Lives», «Chicken Man», «Painful Eliminations», «Mr. Bigglesworth» и от двух человек — основателей университета. Известный член сообщества Хаскелл из Credit Suisse сказал нам, что его работодатель серьезно инвестировал в Хаскелл с более чем сотней разработчиков и что он лично отвечал за большую часть своей разработки на Хаскелле, но это оказалось ещё одним обманом. В Credit Suisse сотни разработчиков, использующих другие языки, он же был большой частью небольшого числа разработчиков Хаскелла, и Хаскелл никогда не интересовал Credit Suisse (они просто поддерживают унаследованный код на Хаскелле). Erlang Training and Consulting были размещены на странице Haskell in Industry как спам. Очевидно, они никогда не использовали Хаскелл. Galois, по-видимому, является единственной в мире самодостаточной компанией, серьезно инвестировавшей в Хаскелл, но их единственный известный разработчик примечателен только тем, что упоминает о своей диссертации на LinkedIn, которую он не ещё защитил, и за создание огромных количеств бессодержательной пропаганды, таких как анализ делегатов вышеупомянутой конференции Хаскелл и его анализ IRC-чатов. Nokia была ссылкой на рекламное объявление, не связанное напрямую с Хаскеллем. Openomy была ссылкой на блог без каких-либо продуктов. Многие «стартапы», включая Red Nucleus, были перечислены, но и никогда не увидели света. SeeReason Partners, LLC была компанией, в которой нет продуктов или услуг, не говоря уже о связанных с Хаскеллем. Один из «учредителей» заверил нас в 2007 году, что они будут создавать настоящую страницу компании, но этого так и не произошло. С нашей точки зрения, этот систематический обман общественности большинством видными членами сообщества Хаскелла был последним гвоздем в гробу Хаскелла. Независимо от технических достоинств риск быть связанным с такими людьми слишком велик.
  • Недружелюбеность к пользователю. Одина только установка компилятора — это кошмар (установка GHC 6.12 заняла у меня 2 дня!). А с библиотеками ещё хуже. Попытка установки с такой болью имеют такой же смысл, как посещение стоматолога без анестезии.
  • Коммерческая недружелюбность. Вся инфраструктура Хаскелла основана на предположении, что программное обеспечение распространяется в исходниках. Никто никогда не продавал программистам на Хаскелле библиотеки на Хаскелле с закрытыми исходниками. Поэтому мы можем рассчитывать только на продажу исходного кода (ненужный риск, который не был навязыван конкурирующими языками), или на использование его на дому. Почти все пользователи Хаскелла являются не коммерсантами, а учеными. И многие, как и Норман Рэмси, сильно противодействуют индустрии ПО.
  • Не рекомендуется. Даже Саймон Пейтон-Джонс отговаривает использовать Хаскелл в промышленности, потому что они не хотят и не намерены поддерживать реальных пользователей. Хаскелл — исследовательский проект с постоянными экспериментами, постоянно подвергающийся риску серьезных изменений.
  • Плохая наука. Сообщество Хаскелла создает беспрецедентное количество плохой науки, излагая вывод о том, что Хаскелл велик. Оно использует каждый трюк в книге, чтобы заставить сделать такой вывод о величии Хаскелла. Во многих случаях для раскрытия истины требуется довольно много усилий. Например, Saynte опубликовал результаты для «наивно» распараллеленных лучей и пришел к выводу, что Хаскелл — это самый простой язык для эффективного распараллеливания, требующий только одного изменения строки. Этот обман был совершен, начав с «серийной» версии, которая уже была тщательно переработана, чтобы сделать её поддающейся распараллеливанию, а затем отключить оптимизацию только для конкурентов (и даже сделать приписку о большом времени компиляции в одном случае!). Делают всё, чтобы Хаскелл выглядел конкурентоспособным. Более того, эта переработка могла быть выполнена только на основе обширного бенчмаркинга и разработки. Даже ученые, публикующие исследования о Хаскелле, подходят к этому. Например, в недавней работе «Регулярные полиморфные параллельные массивы» Мануэль Чакраварти и др. искусственно сокращают разрыв между Хаскеллом и Си, сравнивая только игнорирующие кэш алгоритмы (которые тратят все свое время на ненужные промахи в кэше). Он некорректно заявляет, что такие алгоритмы «широко используемы», описывает однострочное изменение, необходимое для распараллеливания Си как «значительные дополнительные усилия», несмотря на то, что как последовательные, так и параллельные решения Си значительно более кратки, чем их соответствующие из Хаскелла. Мне было отказано в предоставлении кода C, чтобы я мог проверить их выводы (пока я не опубликовал это блоге), и были выборочно взяты наивысшие результаты работы Хаскелла в зависимости от количества потоков (которые достигают непредсказуемого числа, прежде чем увидеть ухудшение производительности). Когда я высказал свои опасения, Дон Стюарт, злоупотребляя статусом модератора на форуме, удалил мои критические замечания. На сегодняшний день эти недостатки в документе не были рассмотрены.

Поэтому я решил, что мы будем ориентрироваться на F# вместо Хаскелла. В свете ретроспективного решения это было абсолютно правильным решением. Возможно, другие люди рискнут, используя Хаскелл в работе, но я настоятельно рекомендую им быть очень осторожными в отношении «информации», которая, несомненно, будет им предоставлена.

Перевод с английского, автор: Jon Harrop, 2010 г., оригинал: Why is Haskell used so little in the industry?

Опубликовано: 2018.03.24, последняя правка: 2021.04.22    08:36

ОценитеОценки посетителей
   ██████████████████████████████████████████ 2 (100%)
   ▌ 0
   ▌ 0
   ▌ 0

Добавить свой отзыв

Написать автору можно на электронную почту
mail(аt)compiler.su

Авторизация

Регистрация

Выслать пароль

Карта сайта


Содержание

Каким должен быть язык программирования?

Анализ и критика

Описание языка

Компилятор

Отечественные разработки

Cтатьи на компьютерные темы

●  О превращении кибернетики в шаманство

●  Про лебедей, раков и щук

●  О русском ассемблере

●  Арифметика синтаксиса-3

●  Концепция владения в Rust на примерах

●●  Концепция владения в Rust на примерах, часть 2

●●  Концепция владения в Rust на примерах, часть 3

●  Суть побочных эффектов в чисто функциональных языках

●  О неулучшаемой архитектуре процессоров

●  Двадцать тысяч строк кода, которые потрясут мир?

●  Почему владение/заимствование в Rust такое сложное?

●  Масштабируемые архитектуры программ

●  О создании языков

●●  Джоэл Спольски о функциональном программировании

●  Почему Хаскелл так мало используется в отрасли?

●  Программирование исчезнет. Будет дрессировка нейронных сетей

●  О глупости «программирования на естественном языке»

●  Десятка худших фич C#

●  Бесплатный софт в мышеловке

●  Исповедь правового нигилиста

●  ЕС ЭВМ — это измена, трусость и обман?

●  Русской операционной системой должна стать ReactOS

●  Почему обречён язык Форт

●  Программирование без программистов — это медицина без врачей

●  Электроника без электронщиков

●  Программисты-профессионалы и программирующие инженеры

●  Статьи Дмитрия Караваева

●●  Идеальный транслятор

●●  В защиту PL/1

●●  К вопросу о совершенствовании языка программирования

●●  Опыт самостоятельного развития средства программирования в РКК «Энергия»

●●  О реализации метода оптимизации при компиляции

●●  О реализации метода распределения регистров при компиляции

●●  О распределении памяти при выполнении теста Кнута

●●  Опыты со стеком или «чемпионат по выполнению теста Кнута»

●●  О размещении переменных в стеке

●●  Сколько проходов должно быть у транслятора?

●●  Чтение лексем

●●  Экстракоды при синтезе программ

●●  Об исключенных командах или за что «списали» инструкцию INTO?

●●  Типы в инженерных задачах

●●  Непрерывное компилирование

●●  Об одной реализации специализированных операторов ввода-вывода

●●  Особенности реализации структурной обработки исключений в Win64

●●  О русском языке в программировании

●●  Формула расчета точности для умножения

●●  Права доступа к переменным

●●  Заметки о выходе из функции без значения и зеркальности get и put

●●  Модификация исполняемого кода как способ реализации массивов с изменяемыми границами

●●  Ошибка при отсутствии выполняемых действий

●●  О PL/1 и почему в нём не зарезервированы ключевые слова

●●  Не поминайте всуе PL/1

●●  Скорость в попугаях

●●  Крах операции «Инкогнито»

●●  Предопределённый результат

●●  Поддержка профилирования кода программы на низком уровне

●●  К вопросу о парадигмах

●  Следующие 7000 языков программирования

●●  Что нового с 1966 года?

●●  Наблюдаемая эволюция языка программирования

●●  Ряд важных языков в 2017 году

●●  Слоны в комнате

●●  Следующие 7000 языков программирования: заключение

Компьютерный юмор

Новости и прочее




Последние отзывы

2024/03/29 14:49 ••• Ivan
Энтузиасты-разработчики компиляторов и их проекты

2024/03/27 19:12 ••• MihalNik
Постфиксные инкремент и декремент

2024/03/22 20:41 ••• void
Раскрутка компилятора

2024/03/20 19:54 ••• kt
О многократном резервировании функций

2024/03/20 13:13 ••• Неслучайный читатель
Надёжные программы из ненадёжных компонентов

2024/03/10 18:33 ••• Бурановский дедушка
Русской операционной системой должна стать ReactOS

2024/03/07 14:16 ••• Неслучайный читатель
«Двухмерный» синтаксис Python

2024/03/03 16:49 ••• Автор сайта
О неправомерном доступе к памяти через указатели

2024/02/28 18:59 ••• Вежливый Лис
Про лебедей, раков и щук

2024/02/24 18:10 ••• Бурановский дедушка
ЕС ЭВМ — это измена, трусость и обман?

2024/02/22 15:57 ••• Автор сайта
Русский язык и программирование

2024/02/19 17:58 ••• Сорок Сороков
О русском языке в программировании

2024/02/16 16:33 ••• Клихальт
Избранные компьютерные анекдоты