Пользователь
0,0
рейтинг
12 ноября 2015 в 05:30

Разработка → Выбор языка (Haskell vs Go) перевод

Перевод статьи о вопросе выбора языка и компромиссе сложности и продуктивности.

Предупреждение: это разглагольствование.

Недавно я сделал очередной большой шаг вперед на своём пути просвещения в Хаскеле. Наконец-то я вижу, как много различных частей мозаики Хаскеля гармонично складываются воедино. На этом моменте, я почувствовал, что готов идти вперёд и писать полезные программы. Я прочёл исходный код web-фреймворка Scotty и был приятно удивлён тем, что я прекрасно понимал, как он работает. Я полностью влюблён в Хаскель. Мне нравится, что он заставляет тебя думать. Ты не просто открываешь текстовый редактор и начинаешь ударять по клавишам, чтобы написать программу на Хаскеле. Я люблю то, что Хаскель поощряет обобщения и абстракции. Одним из «эврика»-моментов в моём пути было понимание всех последствий того, почему функция типа a -> a имеет только одну реализацию. Я подсел на возможность запустить программу в первый раз и знать, что она заработает (после борьбы с компилятором целую вечность). Я думаю, что монады и линзы — очень умные вещи. Да по многим критериям, Haskell — идеальный язык программирования.

И у меня заняло 4 года прийти к этому.

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

Я также игрался с Purescript — это диалект Хаскеля, который компилируется в Javascript. По многим параметрам, Purescript намного лучше Хаскеля, потому что у него нет того исторического багажа. Но общаясь с моим коллегой, который не знает Purescript, о том, чтобы начать использовать его в нашей кодовой базе, я понял всю тяжесть того, что я просил его выучить. Это, конечно, звучит здорово — сказать «Давайте перепишем это на Purescript» и ожидать, что кто-то вернется после выходных, выучив его достаточно хорошо, при том, что у меня самого это заняло 4 года.

Другой отличный пример это open source сообщество. Если вы выбрали Хаскель для вашего open source проекта, вы будете продуктивны, сможете безопасно рефакторить код, писать мало кода — но как много людей захотят выучить Хаскель, чтобы внести свой вклад в ваш проект или сделать фикс?

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

И при всём этом, Go оказывается гораздо более популярным, чем Хаскель, если верить GitHub. Внезапно, на Go уже написано так много потрясающих проектов, вроде Docker, InfluxDB, etcd, consul, prometheus, packer и многих других. В отличие от Хаскеля, если вы попросите коллегу выучить Go за одни выходные, они вернутся с небольшой программой, которую они уже смогли написать на нём. Почему-то безусловно более плохой инструмент используется массами, чтобы создавать крутые вещи.

Что мы должны из этого вынести? Выбор языка программирования имеет значение. Программирование — это социальная деятельность. Похоже, «меньше фич» равняется «проще освоить». Обобщение и инновации в языках программирования, похоже, выходят из моды. Создавать программы, которые решают реальные задачи оказывается более важным, чем использовать острый топор. Мы почти наверняка предпочтём худший инструмент, которым легко пользоваться без надобности читать инструкцию. Мы скорее предпочтём щелкнуть фото своим смартфоном, чем учиться, как пользоваться профессиональной зеркальной камерой.
Перевод: Honza Pokorny
divan0 @divan0
карма
135,0
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (81)

  • +17
    [sarcasm]
    Хороший материал. Надо бы еще assembler с javascript сравнить…
    [/sarcasm]
    • –1
      Имхо, в статье не сравниваются языки.
      Да и haskell vs go совсем не то же самое, что asm vs js. Так что такой себе сарказм )
  • +1
    А может всё проще — хаскел переусложнён там, где мог бы быть простым?
    • +5
      В каком смысле переусложнён? Вы считаете, что всю ту же выразительную мощность можно было реализовать проще и понятнее?
      • –5
        В прямом — используются идиомы, которые чужды обычному человеку. А выразительную мощь можно натянуть на любые идиомы.
        • +1
          используются идиомы, которые чужды обычному человеку

          Что значит «чужды обычному человеку»? И кто такой «обычный человек»? Сразу в голову приходит пример: числа. Ну, 2 яблока + 4 яблока — это понятно, а что такое 2 + 4 — нет. Ну т.е. вот какая-либо теория множеств или теория типов — они чужды обычному человеку?
          А выразительную мощь можно натянуть на любые идиомы.

          Что вы хотели этим сказать? Вы отрицаете различную выразительную мощность у разных языков программирования?
          • –2
            Обычный человек — это такое устройство, которое не потеряло связь с реальным миром, где есть объекты, у объектов есть состояния, а классы определяются по набору признаков. И таки считает он площадь сферы по формуле, а не выразительно мощно интегрирует её по поверхности. Не всем дано быть математиками, а написание прикладного по — задача скорее переводчика, чем математика.

            Нет, я отрицаю причинно-следственную связь между ФП и выразительной мощностью. Это перпендикулярные вещи.
            • +3
              не потеряло связь с реальным миром

              В реальном мире нет чисел. И сфер нет. Вы считаете, что математика — плохой инструмент для моделирования реальности (похоже, я как-то задавал этот вопрос на Хабре, и мне кажется, что даже вам)?

              Нет

              Ну так вы считаете, что всю ту же выразительную мощность можно было реализовать проще и понятнее?
              • –3
                Я вам открою страшную тайну, но человек оперирует с числами через вполне себе конкретные аудио-визуальные образы. Числа — это как универсальная валюта, в которую можно конвертировать множество других предметов.

                Через более понятные обычным людям идиомы — безусловно.
                • +3
                  Э нет. Разные люди оперируют с числами (и вообще абстракциями) по-разному, далеко не всем для этого нужны аудиовизуальные образы.
                  • –1
                    Разные люди оперируют с числами (и вообще абстракциями) по-разному

                    И как ещё они оперируют, кроме аудиовизуальных образов?
                    • 0
                      Если при мысленном расчёте предела функции человек представляет запись этого предела, как на бумаге, то этот образ с реальным миром связан только тем, что похож на запись на бумаге. Аналогично различные диаграммы и прочее связаны с реальным миром только тем, что они похоже на какую-то визуальную картинку, но это не «конкретный образ». Вот я когда числа складываю, вижу их циферную запись, в чём тут конкретика? Это искусственная вещь.
                      В этом смысле всё связано с реальным миром, даже идиомы Haskell, достаточно представлять их код в голове.
                    • +5
                      На уровне понятий. Собственно, этим абстрактное мышление и отличается от предметного.
                      • 0
                        А «понятия», как, по-вашему, в мозгу представлены?
                        • +4
                          Нейрончиками и их связями, я подозреваю. Но вообще, конечно, это к психофизиологам.
                        • +3
                          Это не ответ на вопрос, но всё же.
                          Вот как представлено понятие «верх»? Тут можно вспомнить эксперименты про ношение очков, переворачивающих изображение. Со временем человек привыкает, и хоть картинка остаётся как бы перевёрнутой, для экспериментируемого она перестаёт быть перевёрнутой, потому что «верх» — это то, куда показывает поднятая рука. Т.е. «верх» у него становится визуально снизу, но для него это так же нормально, как для нас то, что «верх» — сверху. У него-то «верх» — тоже сверху :)
                • +3
                  Вы не ответили на вопрос о том, считаете ли математику не лучшим инструментом для моделирования реальности в той или иной области? Вот как по мне, так одна проблема, но существенная, сложность для человека, которую (проблему), на мой взгляд, лучше решать улучшением преподавания математики и упрощением (но не в ущерб строгости и выразительности) математики, а не заменой менее формальными инструментами.

                  Через более понятные обычным людям идиомы — безусловно.

                  Хорошо. Понятно, что пока мы не умеем строго считать выразительную мощность, мнения относительно оной могут сильно различаться, но тем не менее, есть пример простого аналога, к примеру, монад? Просто на мой взгляд, там и так уже проще некуда, что может быть проще трёх функций с определённым законами? Ну или взять линзы, там вообще просто обобщённая функция, а через одну неё и геттер и сеттер и много что ещё. Это опять же проще, чем какие-то навороченные объекты отдельно с геттерами и сеттерами (хотя вторые проще для понимания, но менее выразительны).
                  Вот только эта простота — не easy, а simple, поэтому порог входа высокий, но если понижать порог входа, то simpleness потеряется.
                  • –2
                    Строгость и выразительность не является прерогативой исключительно функциональных языков.

                    Монады — это костыль, позволяющий спрятать изменяемое состояние под ковёр, притворившись будто его нет. Зачем они в императивном языке — ума не приложу :-)
                    • +4
                      Зачем они в императивном языке — ума не приложу

                      А вы думаете, что монады — это только IO? Например, монада Maybe сильно упрощает работу с null, монада Try — работу с ошибками (и да, я все еще говорю об императивных языках), да собственно даже удобная работа с коллекциями — это монада.
                      • 0
                        А вы думаете, что изменяемое состояние есть только в IO? :-) Все перечисленные монады прячут в себе промежуточный результат вычислений.
                        • 0
                          Вот только промежуточный результат вычислений — это не обязательно изменямое состояние. И для его передачи не обязательна монада.
                    • +2
                      Зачем они в императивном языке — ума не приложу :-)

                      То-то их тянут в императивные языки. Что LINQ в C#, что for в Scala.
                    • +1
                      Монада — всего лишь абстракция связывания вычислений, способ переопределить «оператор ;», очень удобный синтаксический сахар.
                    • +3
                      > Монады — это костыль, позволяющий спрятать изменяемое состояние под ковёр, притворившись будто его нет.

                      Я, конечно, не уверен, но мне кажется что перед тем как высказывать экспертное мнение, стоит ознакамливаться с материалом. Тогда будет понятно зачем монады были введены, как используются и чем могут быть заменены и в каких языках.
                • 0
                  Я там выше ответил про аудио-визуальные образы. Я числа представляю обычно в виде циферной их записи — это никак не идёт под раздел «конкретный аудио-визуальный образ», потому что с тем же успехом можно и монады представлять, в виде их записи в мат. нотации, ну или кода. Связи с реальностью будет не меньше.
                  • 0
                    Я числа представляю обычно в виде циферной их записи — это никак не идёт под раздел «конкретный аудио-визуальный образ»

                    В моем понимании, идет. Когда вы оперируете числами, у вас возбуждаются определенные группы нейронов в визуальной и слуховой коре — а это и есть «аудиовизуальные образы».
                    • 0
                      Прочтите комментарий исходный, с которого зашла речь про образы. Там про то, что вот де Haskell — далёк от человека. В моем, и, судя по всему, вашем понимании — теория категорий не дальше чисел, там диаграммы всякие, весьма наглядно. Но вряд ли это то, что имел в виду vintage
                • +5
                  Т.е. ты, когда складываешь 2+2 или считаешь сдачу со ста рублей, вместо простого использования заученных с детства правил начинаешь представлять себе яблоки или какие другие «конкретные аудио-визуальные образы»?

                  И заодно: Обычный человек — это такое устройство, которое не потеряло связь с реальным миром, где есть объекты, у объектов есть состояния, а классы определяются по набору признаков.

                  Ну расскажи про состояние числа 2, какой у него класс и какие признаки. И насколько это знание в реальном мире поможет тебе посчитать сдачу в магазине.
                  • –1
                    Именно так, я представляю закорючку «2» написанную чернилами на пергаменте, ещё одну закорючку «2», закорючку "+" и тут же всплывает ассоциативная связь с образом «2+2=4», где я распознаю закорючку «4». Для компьютера всё есть биты, для человека всё есть образы.
                    • +4
                      Ну так представьте закорючки для join, fmap и return, кто ж вам мешает?
    • 0
      Haskell очень прост и минималистичен. Просто непривычен для воспитанных на императивной парадигме и многословном синтаксисе.
  • +4
    Думаю, сложность вызывает функциональное программирование, а не сам язык. Сравнение Хаскеля (или другого функционального языка программирования) с любым другим императивным языком программирования даст похожий результат.
    • +3
      Программировать в функциональном стиле можно почти на любом ЯП.
      • +3
        если под функциональным стилем понимается использование map и reduce, и немножко замыканий, то конечно можно.
        • 0
          Ну лямбды, функции высшего порядка, чистые функции, каррирование, и т.д. — все это хоть в том же JS можно делать. Я уж не говорю про рекурсию.
          • +1
            наверное можно, но не придётся ли потратить те же четыре года, чтобы делать это правильно, особенно когда за тобой не приглядыват компилятор?
            • 0
              Ну не 4, а чуть меньше, но согласен.
              Но с другой стороны, на любом языке можно писать такое, что волосы по ночам будут шевелиться во всех местах.
              Так что, по моему мнению, уж лучше самому учиться писать хорошо.
              • +1
                Плохой код будет плох на любом языке и при любом подходе. Не просто переключится с императивного программирования на функциональное (хотя может кому-то и легко) и язык тут не важен.
          • –2
            То, что эти идиомы впервые появились в функциональных языках и то по необходимости не делает ваш императивный код с использованием этих идиом функциональным ни в коей мере :-)
            • +1
              Суть не в словах, а в том, что за ними стоит. Функциональное программирование — это использование определенного подхода, а не языка при написании кода. Емнип, в том же Хаскеле можно и в императивном стиле писать (сам не видел, каюсь, но рассказывали коллеги).
              К слову, лямбда-исчисление изначально не имело никакого отношения к ЯП (их тогда и не было).
              • –1
                ФП — это «программирование без изменения состояния», а не «программирование с использованием замыканий».
                • 0
                  > «программирование с использованием замыканий»

                  А я где-то это утверждал?
                  • –1
                    Тут: http://habrahabr.ru/post/270707/#comment_8651791
                    И для справки: чистая функция — не только не меняет состояние, но и не зависит от изменяемого состояния, чего на JS достичь практически невозможно.
                    • 0
                      > Тут: habrahabr.ru/post/270707/#comment_8651791

                      А процитируйте плз, где я сказал, что ФП — это «программирование с использованием замыканий».

                      > И для справки: чистая функция — не только не меняет состояние, но и не зависит от изменяемого состояния, чего на JS достичь практически невозможно.

                      Странно, а определение чистой функции говорит нам следующее:

                      1. является детерминированной
                      2. не обладает побочными эффектами
                      • 0
                        как бы:
                        является детерминированной = не зависит от внешнего состояния
                        не обладает побочнвми эффектами = не меняет состояние
                        • 0
                          Функция является детерминированной, если для одного и того же набора входных значений она возвращает одинаковый результат. Все.
                          Побочные эффекты — это модификация глобальных переменных, переданных параметров и т.п.
                          Вы таки думаете, что этого невозможно достичь хоть на том же питоне или js?
                          • –1
                            Простой пример: function summ( a, b ){ return a + b }
                            Функция детерменированная? Вроде да. Давайте проверим:

                            var i = 0
                            var a = { valueOf(){ return i++ } }
                            console.log( summ( a, 1 ) ) // 1
                            console.log( summ( a, 1 ) ) // 2

                            Ой.
                            • 0
                              Нет, по описанию этой функции нельзя сказать, детерминированная ли она.

                              (Привет слабой типизации)
                              • 0
                                Недетерменированная функция — это функция, про которую нельзя сказать, что она детерменирована, а не та, которая на каждый вызов возвращает разные значения.
                                • +2
                                  Не вдаваясь в терминологический спор, замечу, что про эту функцию нельзя сказать, что она детерминирована.
                                  • 0
                                    О том и речь, в JS очень сложно создать чистую функцию, а когда всё же удаётся, результат довольно бесполезен.
                                    • 0
                                      Конечно, бесполезен. То-то весь React на этом построен. Хороший, годный react-компонент — это как раз чистая функция State->VDOM, а уж с персистентными структурами данных так и просто сияет.
                            • 0
                              Стойте, но мы же передаем разные входные значения (пусть и опосредованно, через переменную).
                              • 0
                                Нет, передаётся один и тот же объект «a» и константа «1».
                                А то, что результат выполнения опосредованно зависит от глобального состояния — в этом и есть суть недетерминированности.
                                • 0
                                  Ну так этого можно же избежать простыми действиями.
                                  Я согласен, что тот же Хаскел в этом плане способствует (взять ту же концепцию immutable data).
                                  Но это же не значит, что нельзя делать ФП в других языках.
                                  • –1
                                    Использование функций высшего порядка не делает ваш императивный код функциональным. Точно так же, как костюм утки не сделает из вас утку. Даже если вы будете правдоподобно крякать :-)
                                    • 0
                                      А что делает код функциональным? Использование хаскеля? Или таки следование неким правилам написания кода?
  • +9
    Я даже не думал, что кто-то додумается переводить этот горе-вброс. Пщ против хачкеля, lmao.

    Ваня, никогда не разочаровываешь.
  • +7
    я честно не понимаю сути такого сравнения языков, а тем более приведения в качестве какого-либо аргумента успешные проекты.
    Причем на доводы о том, что в языке чего-то не хватает, или что какие-то вещи реализованы неверно, приводятся агрументы, вида
    «а мне/успешному проекту, оно не нужно» или «а зато у нас докер». Как будто, что-либо мешает писать на языке успешные продукты,
    ну плохой язык, ну и что, вещи практически независимые, в итоге максимальной популярностью обычно начинает пользоваться самый плохой инструмент из достаточных для решения задачи. А успешность написания программ зависит от качества программистов и менеджеров. Особенно аргумент про продукты тоже интересен, я подозреваю, что в NY больше го программистов, чем программистов на Haskell, пишущих публичные продукты, так что результат не сильно удивителен.
    • +1
      А я иначе эту статью вижу. Она про конфликт между понятиями «хороший»/«плохой» между теоретиками и практиками. Когда ты один, ради интереса учишь языки, пытаешься на них что-нибудь «выражать» на синтетических или не очень примерах — у тебя одни представления о том, что будет хорошо, а что нет. Когда же ты попадаешь в «реальный мир» — работаешь с массой других людей, разных компаний, большим количеством чужого кода — начинаешь совсем иначе относиться. И в этой статье как раз хорошо проиллюстрирован вот этот сдвиг (хоть и не окончательный) приоритетов с «теоретика» на «практика» — автор только коммуницируя с другими начал понимать, что возможно, то что ему кажется «объективно хорошим» — не совсем то, что нужно в реальном мире.
      • +7
        мне определенно не нравится деление на «теоретиков» и «практиков», это похоже на попытку спрятатья за какую-то ширмочку. Но в целом в «реальном мире» указанные «теоритические» технологии вполне себе успешно используются. Ну и ещё раз скажу, чуть другими словами, хорошесть/плохость языка и применимость или уместность его для конкретного проекта выполняемого конкретной комадной это разные категории.
        • +2
          Об этом и речь — шкала должна быть в практической уместности и применимости реальными командами на реальных проектах. Go вызывает столько эмоций и его так расхваливают, потому что он даёт возможность быстро и качественно сделать работу при меньших затратах практически в любой команде. Поэтому когда начинают разглагольствовать о теоретических обоснованиях, почему Go плох — это другая категория, другой взгляд вообще на вещи.

          Я нередко слышу от гоферов, что они выбрали Go просто потому что быстро позволил писать крутой софт. Если завтра появится ещё более удачное решение, которое будет более практично и будет позволять более быстрее делать такой же качественный результат — не моргнув глазом, перейдут с Го на него. Я и сам абсолютно такого же мнения. И это то, что я называю «практиками».

          А «теоретики» (в моей терминологии) — строят какую-то искусственную систему координат, в которую вписывают инструменты, и судят с пеной у рта о языках по ней, часто на много-много лет закрывая себя только в рамках одного языка.

          Хотя, возможно, моя терминология не сильно удачная, и можно лучше придумать. Но, я надеюсь, понятно, что в этой модели нет никаких проблем, что языки вроде Хаскеля реально используются в реальных проектах — если это практично (например, команда знает очень хорошо только хаскель — почему нет?), то это хороший выбор.
          • +2
            В целом согласен.
            Кстати, я слышу от хаскелистов то, что они выбирают Haskell, т.к. он дает им возможность качествено и быстро писать софт и легко его поддерживать, при этом у большинства их них в бекграунде есть пачка императивных языков, включая Go. Я правда с Go не знаком настолько, чтобы обсуждать его в данном контексте (практики написания крутых программ). Произошло это т.к. причин продолжать его изучение дальше, чем базовые tutorial-ы, я не увидел. Но даже на этом уровне по сравнению с другими языками той же категории (на мой взгляд python и компания, он выглядит вполне пристойно). Т.е. если я, по какой-то причине, возьмусь писать крутой софт на Go, то я буду страдать от отсуствия возможностей, которые я хотел бы видеть, в языке и с которыми привык работать (те самые теоритические обоснования). В тоже время, замечу, есть достаточно мало областей, где эти причины стали бы для непреодолимой проблемой. как-то так…
  • 0
    > в итоге максимальной популярностью обычно начинает пользоваться самый плохой инструмент из достаточных для решения задачи

    Выходит, самые лучшие вещи пишутся на самых непопулярных языках и сами не пользуются популярностью? Боже мой, вы открыли нам всем глаза — пойду искать веб-фреймворк на брейнфаке.
    • +1
    • +1
      Вы сознательно пропустили часть процитировнной Вами фразы? Бреинфак, не является разумным образом, достаточным для написания веб фреймворка. PHP, например, является, и несмотря на все проблемы языка, особенно в версиях 4.x мы можем видеть множество решений на нём.
      Соглашусь, что из моей фразы совершенно непонятно почему иногда наблюдаются мирграции на язык с меньшими проблемами, но это нужно гораздо точнее формулировать фразу или сильно расписывать, а мне лень.
      • 0
        Причем тут 4 версия PHP? Доступность — вот, что действительно двигает. Создатели того же docker, я уверен, оценивали именно доступность, а не сидели и не выбирали, чего бы им такого придумать, чтобы побольше задниц рвануло. И еще такой параметр как субъективный порог вхождения. Ничего не хочу сказать плохого, но на ruby у меня не смоглось писать, на php я выстрадал… Python завелся вообще легко. Go — тоже оказался достаточно простым. Отсутствие дженериков я лично воспринимаю как несущественную претензию. То есть, это может быть ответом на вопрос «почему ты не выбрал этот язык?», но не показателем качества языка, как по мне. Возможно, в дальнейшем я поменяю свое мнение, но вот сейчас у меня тот самый щенячий восторг неофита от того, что я прогаю, а оно работает. Многословность работы с ошибками вообще не смущает. Тут дело вот, в чем, есть языки, на которых говнокод объективно воспринимается не так ужасно. А есть языки, где надо сначала основательно подумать. И это тоже — субъективный взгляд.
        • +2
          версия PHP 4 тут при том, что является примером моему утверждению, а brainfuck нет. Пример был необходим, чтобы больше не возникало идей для передергиваний.

          Создателями обычно двигает знание языка, знание похожих языков, наличие готовых библиотек, наличие знаний у команды. Возможно то, что вы называете «субьективной легкостью вхождения». Наприме, если у вас тут есть команда людей на OCaml, а вам нужно написать сложный проект, с большим количеством шаблонного кода, то вы возьмете MetaML, а не go, python или что-либо ещё, на что команда явно потратит больше времени на изучение.

          Ещё раз повторюсь, язык не должен быть хорошим, для того чтобы на нём можно было успешно писать, он должен быть достаточным, чтобы на нём ваша команда могла решать поставленные перед вами задачи, а его экосистема должна иметь нужные вам средства для работы (библиотеки/утилиты/документацию/статьи). В го нету очень многого, с точки зрения CS это огромный шаг назад в развитии, никакого анализа решений на рынке, результатов в науке — это плохо? Ну с точки зрения программиста, наверное да, но только когда эти возможности ему нужны. Т.е. в обем-то ответ на половину упрёков (разумных естественно), может быть «да, плохо, решается так (ссылка), ну и что дальше?».
          Например, тот же haskell тоже далеко не идеален, метапрограммитование только generic-s (не путать с явовыми) и ужасный TempateHaskell, kinds equal types нету, т.е. никаких там зависимых типов (кроме костылей с синглетонами), function patterns — нет не завезли, и это если не углубляться, причем в разных языках рядом все это есть, но для решения повседневных задач это не нужно.
          • 0
            И как ваши слова бьются с вашими же словами о том, что самое успешное ПО написано на самом дерьмовом языке. Если, о боже, так много вокруг отличного ПО, написанного на какой-то какашке, то а) это тенденция и б) что-то не так… Причем «что-то не так» — это повод задать себе вопрос «что со мной не так?»

            Снова же — только личная точка зрения, ничего больше.

            ЗЫ. Опять же, лично моя точка зрения. Вечернее платье, например. Хорошо себе представим платье, яркое, как оно приятно подчеркивает достоинства барышни. А потом вы общаетесь с барышней поближе, и вот утром эта барышня уже без дженериков и без темплейтов, в вашей футболке, пьет кофе и пытается с вами познакомиться. Так же и здесь. Я много раз пытался подступиться к эрлангу, к яве — чего там только нет. Но мне не нужна барышня в вечернем платье каждый день. Сказать по правде, барышня в вечернем платье меня вообще уже больше не интересует — мне надо милую девушку в облегающих шортах, и чтобы не было ничего лишнего. Может быть, в этом дело? Одни языки пытаются быть такими из себя важными, такими надменными. А есть языки, которые, пусть и обладают недостатками, но с ними легко.
            • +2
              Мне кажется, что вы берёте на себя очень большую смелось переиначивать мои слова и добавлять мне мысли, которых я не думал и не высказывал.
  • 0
    Я что-то вот не понимаю, уже не первая (и явно не последняя) статья о сравнении языков, о том кто лучше, кто хуже, у кого какие проблемы и т.д.
    А вот почему микроскоп лучше молотка? и тем и другим можно забивать гвозди, если того требует ситуация и задача. Но это далеко не значит, что молотком можно изучать микроорганизмы.
    Проблемы есть у всех яп. Нет и не будет идеального языка программирования, просто потому что «человеки» никогда не придут к единому мнению, всегда кто-то будет против чего-то. И поэтому выбирать язык для создания того или иного проекта наверное имеет смысл не по тому на сколько «острое у него лезвие топора», а на сколько дешево\быстро\качественно\расширяемо\затратно создать прототип и выкинуть на рынок.
    Вот php — плохой язык, так все говорят повально. Он создан умирать, — говорят в каждом подобном топике. Тем не менее на нем сделано уйма полезных и хороших продуктов. C# тоже многим не нравится, Python также находит своих недоброжелателей, но как-то это не меняет предыдущего высказывания.
    Так может уже перестать сравнивать теплое с мягким или жидкое с соленым? Я бы вот с радостью узнал в каких областях тот или иной язык лучше применять и почему. Да, знать минусы надо и хорошо, что о них рассказывается. Но полемика ради полемики же во всем остальном, разве нет?
    • +3
      Он создан умирать, — говорят в каждом подобном топике

      Эта фраза не означает, что язык должен умереть и исчезнуть.
      Это сказано в том смысле, что на PHP не стоит делать программы, крутящиеся в вечном цикле. Он рассчитан на инициализацию, обработку запроса, завершение.
      • +1
        Корни высказывания вполне понятны, а вот смысл вкладываемый в нее многими ораторами, скорее всего, не так однозначен.
    • 0
      Ну вообще-то в статье четко сказано, что на haskell вы будете гораздо продуктивнее, а начит быстрее выбросите прототип на рынок и приводятся аргументы в виде недостатков go. Области применения у языков общего назначения (в отличии от php) тоже одинаковые, это сравнение одного универсального молотка с другим.
      • 0
        Что-то мне не кажется, что 4 года потраченного на изучения haskell будут продуктивнее быстрого старта с go. В общем-то я ничего не имею против, но было бы круто увидеть четкое высказыванием например — «изучите {lang} потратив на него N часов и вы получите следующие преимущества, в отличии от [...] потому как имеются такие-то и такие-то преимущества и минусы.» И вот на мой взгляд это куда объективнее при сравнении двух молотков, а статья, лично у меня, вызывает скорее ощущение сравнение микроскопа с молотком. Хотя я могу глубоко заблуждаться и возможно совершенно не понял посыл в статье.
      • 0
        на хаскеле было бы продуктивнее, если бы все писали на хаскеле.
        всетаки большая часть по это скомбинированные примитивы.
        классическая проблема курицы или яйца, помноженная на высокий порог входа.
  • 0
    И при всём этом, Go оказывается гораздо более популярным, чем Хаскель, если верить GitHub. Внезапно, на Go уже написано так много потрясающих проектов, вроде Docker, InfluxDB, etcd, consul, prometheus, packer и многих других.
    У го есть проблемы, но он создан что-бы разрабатывать продукты (своей нишы), а для чего создан хаскель?
    • +5
      Haskell создан для того, чтобы был основной язык для изучения свойств ленивых функциональных языков. В то время на этой нише не было ни одного подобного языка, а запрос был, впрочем за последние 20 лет ситуация не изменилась.
      То, что на Haskell оказывается можно ещё и код писать, это счастливая случайность. И за последние годы Haskell экосистема заметно продвинулась в данном направлении.
      • 0
        То, что на Haskell оказывается можно ещё и код писать, это счастливая случайность.

        Это реально так или просто излишнее утрирование?
        • +9
          Скорее реально, лучше распишу полностью, чтобы не было недоговоренного, или если что меня бы поправили. Изначально Haskell академический язык и песочница для различных исследований и проверки концепций, до ~95 года (т.е. около 5 лет существования языка) в нём нельзя было делать полноценного IO и программа это была или подача строки на вход и оно выдавала строку на вывод, или чуть-чуть расширенный набор примитивов. Называть такой язык не исследовательским языком тяжело и языком на котором можно писать программы тяжело. Однако среди авторов языка и тех кто с ним работал были и люди, которые двигали его в сторону, где его использование в общем случае было бы возможно. В районе ghc-6.12 уже стало достаточно пристойно, хотя и все равно было много вопросов. В общем-то языком, на котором можно писать полезные программы он стал не так и давно, и в планах изначально этого не было, просто так получилось.
          • +1
            Спасибо за подробности, не знал.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.