Обычно люди жалуются насколько неудобно и непродуманно разработан язык программирования Java, а с другой стороны хвалят Haskell за его надежность и простоту в использовании. Учитывая огромную базу, которая принадлежит Google, было бы логичней использовать Haskell. КВ собрали самые интересные ответы пользователей сайта Quora.

Майкл О. Черч

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

Так почему же Google выбрал Java вместо Haskell? И почему они настаивают на использовании языка программирования Go вместо Haskell или Idris сейчас? Запомните это историческое событие: Майкл О. Черч собирается защищать Google, критикуя один из своих любимых языков (Haskell).

В 1998 году исследование в области языков программирования считалось бессмысленным. Большинство великих идей, которые сейчас выходят на первый план в таких языках, как Clojure и Haskell, возникли уже в 1970-х и 80-х годах.

В конце 1990-х Haskell не был столь хорошо продуманным и стабильным языком программирования как сейчас. Реально ли было бы основать компанию масштаба Google при помощи Haskell в 2014 году? Наверное, да. У вас, скорее всего, возникнут некоторые несоответствия при работе с любой сервисной программой, но вы можете найти рынок сбыта, тем самым сделав свой вклад на основе открытого кода в качестве дополнительного дохода компании, и проблема решена. В конце 1990-х годов, когда вы только что рискованно вложили капитал и у вас не было времени на обучение 100 инженеров "непонятному" языку, который (в то время) не имел даже библиотечной поддержки? Наверное, нет. Обсуждение языка Haskell — еще один безнадежный разговор, который неизбежен с инвесторами и который отнимет у вас много времени, вместо того, чтобы качественно разрабатывать новый продукт.

Несмотря ни на что, язык C ++ должен был быть включен в белый список Google. Существует много способов использования данного языка, но даже в 2014 году ни один другой язык не работает также, как он. При создании чего-либо масштаба Google, понадобится язык управляемой памяти. Следует отметить, что людям нравится больше C, и они утверждают, что C ++ является функционально избыточным и ресурсоёмким программным обеспечением. Ведь Google не выгодно, чтобы большое количество программистов писали свои собственные хэш-таблицы и альтернативные строковые типы, поэтому компания (мудро) решила изменить C ++ в лучшую сторону настолько, насколько это возможно. И (хотя я раскритиковал ужасный Legacy Project) я нахожу большую часть кода C++ в Google очень хорошей и намного более наглядной, чем коды в "лучших" языках программирования типичных компаний.

Java (который ценится не так высоко, как C ++ в Google) попал в белый список путем приобретения. Если вы собираетесь поддерживать каждую недоработанную финансируемую кем-то операционную деятельность, то исполнитель оказывает услугу, а затем вы расходуете много Java. Таким образом, язык Java также можно включить в белый список.

Python числится в списке в качестве экспериментального языка "высокого уровня", но (по состоянию на 2011) его необоснованно не рекомендуют пускать в разработку.

Таким образом, основной необходимый набор Google заполняется языками Go, Dart и несколькими другими внутренними языками ... но корпорация не видит необходимости совершенствования Lisp или Haskell. Google не является компанией, которая разрабатывает языки программирования. Действительно, это одна из ошибок, которую делают все из нас (включая меня) относительно Google, ожидая, что она будет "технологическим лидером" во всем. Потом, когда мы узнаем, что компания использует много Java или что она на самом деле не уделяет много внимания качеству игры в продукте G +, мы ошеломлены таким небрежным отношением относительно вещей, которые так важны для нас.

Тем не менее, Google не может позволить себе быть лидером во всем. Является ли использование такого количества Java (за счет Clojure и Haskell) верным решением для технологического лидера? Конечно, нет. Подходит ли это для Google? Вполне возможно. Будем считать это бизнес-решением, о котором нам не известны все показатели. Ошибочно и опасно предположение, что одна компания (торгующая публично, которая подотчетна инвесторам) могла бы быть "технологическим лидером " по всем направлениям. Это лишь наше заоблачное ожидание.

Джонатан Полсон, инженер-программист в Google

У Google существует ряд веских причин не использовать Haskell.

Я работаю в течение многих лет с Python, который был и является одним из поддерживаемых языков Google. Мне часто не хватает доступных внутренних инструментов языка C ++, (библиотек MapReduce, кода форматирования, взаимозависимых фиксаторов, редакторской поддержки автозаполнения ...). И эта потребность все еще существует после *нескольких лет* работы в Python; а Haskell вообще пришлось бы начинать все с нуля.

Проделать все это — тонна работы, а ведь пришлось бы все это сделать по-новому для Haskell. Haskell также должен быть в состоянии поддерживать все стандартные API Google: MapReduce, буфер протокола, BigTable и т.д. И это еще один большой кусок работы.

С другой стороны, Haskell понадобятся также очень хорошие библиотеки. Есть ли у Haskell отличная поддержка i18n? SSL? Машинное обучение? Поддерживаются ли в надлежащем состоянии все эти библиотеки? А проверял ли кто-нибудь работу Haskell до тысячи машин и тысячи запросов в секунду? Хорошо ли он работает? Есть ли непредвиденные проблемы? Все это, наверное, невозможно, но очень рискованно.

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

Однако все существующие языки Google не собираются исчезать. Так что это просто "очередной язык" сотрудников Googlе, с которым придется иметь дело, и язык, который должна поддерживать рабочая группа обслуживания инфраструктур (если я создаю новую базовую API в Google, то я должен сделать также реализацию Haskell). Очевидно, что эти проблемы были решены.

Может быть, Google должен использовать Haskell. Может быть, нет. Но истинная причина заключается не в том, что Haskell слишком трудно освоить.

Тим Армстронг

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

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

Во-вторых, JVM является хорошей платформой с качественным профилированием и средствами контроля, которые важны для проведения операций.

Язык является небольшим ограничением, в котором могут быть реализованы структурные данные в чистом виде. Функциональные структурные данные чрезвычайно интересные и обладают некоторыми преимуществами. Однако ограничивая себя только ими, можно упустить много полезных структурных данных и алгоритмов. При использовании критически важных кодов, вероятно, понадобятся матрицы, хэш-таблицы и другие структуры необходимых данных, чтобы добиться максимальной производительности. Для многих других услуг Google также существуют большие индексы в памяти, кэш и т.д., которые распределены между программными потоками. Существует много способов, при помощи которых можно интегрировать все это в Haskell с различными монадами, но мне кажется, что вы уйдете в минус с Haskell, как только вы тайно поделитесь изменяемым режимом. Я предполагаю, что будет действительно трудно убедить многих специалистов, что это все стоит делать таким непростым способом.