Предупреждение: это разглагольствование.
Недавно я сделал очередной большой шаг вперед на своём пути просвещения в Хаскеле. Наконец-то я вижу, как много различных частей мозаики Хаскеля гармонично складываются воедино. На этом моменте, я почувствовал, что готов идти вперёд и писать полезные программы. Я прочёл исходный код 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 за одни выходные, они вернутся с небольшой программой, которую они уже смогли написать на нём. Почему-то безусловно более плохой инструмент используется массами, чтобы создавать крутые вещи.
Что мы должны из этого вынести? Выбор языка программирования имеет значение. Программирование — это социальная деятельность. Похоже, «меньше фич» равняется «проще освоить». Обобщение и инновации в языках программирования, похоже, выходят из моды. Создавать программы, которые решают реальные задачи оказывается более важным, чем использовать острый топор. Мы почти наверняка предпочтём худший инструмент, которым легко пользоваться без надобности читать инструкцию. Мы скорее предпочтём щелкнуть фото своим смартфоном, чем учиться, как пользоваться профессиональной зеркальной камерой.
Комментарии (81)
vintage
12.11.2015 08:55+1А может всё проще — хаскел переусложнён там, где мог бы быть простым?
VoidEx
12.11.2015 13:57+5В каком смысле переусложнён? Вы считаете, что всю ту же выразительную мощность можно было реализовать проще и понятнее?
vintage
12.11.2015 20:26-5В прямом — используются идиомы, которые чужды обычному человеку. А выразительную мощь можно натянуть на любые идиомы.
VoidEx
12.11.2015 22:20+1используются идиомы, которые чужды обычному человеку
Что значит «чужды обычному человеку»? И кто такой «обычный человек»? Сразу в голову приходит пример: числа. Ну, 2 яблока + 4 яблока — это понятно, а что такое 2 + 4 — нет. Ну т.е. вот какая-либо теория множеств или теория типов — они чужды обычному человеку?
А выразительную мощь можно натянуть на любые идиомы.
Что вы хотели этим сказать? Вы отрицаете различную выразительную мощность у разных языков программирования?vintage
13.11.2015 02:52-2Обычный человек — это такое устройство, которое не потеряло связь с реальным миром, где есть объекты, у объектов есть состояния, а классы определяются по набору признаков. И таки считает он площадь сферы по формуле, а не выразительно мощно интегрирует её по поверхности. Не всем дано быть математиками, а написание прикладного по — задача скорее переводчика, чем математика.
Нет, я отрицаю причинно-следственную связь между ФП и выразительной мощностью. Это перпендикулярные вещи.VoidEx
13.11.2015 03:31+3не потеряло связь с реальным миром
В реальном мире нет чисел. И сфер нет. Вы считаете, что математика — плохой инструмент для моделирования реальности (похоже, я как-то задавал этот вопрос на Хабре, и мне кажется, что даже вам)?
Нет
Ну так вы считаете, что всю ту же выразительную мощность можно было реализовать проще и понятнее?vintage
13.11.2015 08:32-3Я вам открою страшную тайну, но человек оперирует с числами через вполне себе конкретные аудио-визуальные образы. Числа — это как универсальная валюта, в которую можно конвертировать множество других предметов.
Через более понятные обычным людям идиомы — безусловно.
lair
13.11.2015 09:35+3Э нет. Разные люди оперируют с числами (и вообще абстракциями) по-разному, далеко не всем для этого нужны аудиовизуальные образы.
divan0
13.11.2015 10:04-1Разные люди оперируют с числами (и вообще абстракциями) по-разному
И как ещё они оперируют, кроме аудиовизуальных образов?VoidEx
13.11.2015 11:25Если при мысленном расчёте предела функции человек представляет запись этого предела, как на бумаге, то этот образ с реальным миром связан только тем, что похож на запись на бумаге. Аналогично различные диаграммы и прочее связаны с реальным миром только тем, что они похоже на какую-то визуальную картинку, но это не «конкретный образ». Вот я когда числа складываю, вижу их циферную запись, в чём тут конкретика? Это искусственная вещь.
В этом смысле всё связано с реальным миром, даже идиомы Haskell, достаточно представлять их код в голове.
lair
13.11.2015 11:32+5На уровне понятий. Собственно, этим абстрактное мышление и отличается от предметного.
divan0
13.11.2015 17:27А «понятия», как, по-вашему, в мозгу представлены?
lair
13.11.2015 17:29+4Нейрончиками и их связями, я подозреваю. Но вообще, конечно, это к психофизиологам.
VoidEx
13.11.2015 18:03+3Это не ответ на вопрос, но всё же.
Вот как представлено понятие «верх»? Тут можно вспомнить эксперименты про ношение очков, переворачивающих изображение. Со временем человек привыкает, и хоть картинка остаётся как бы перевёрнутой, для экспериментируемого она перестаёт быть перевёрнутой, потому что «верх» — это то, куда показывает поднятая рука. Т.е. «верх» у него становится визуально снизу, но для него это так же нормально, как для нас то, что «верх» — сверху. У него-то «верх» — тоже сверху :)
VoidEx
13.11.2015 11:12+3Вы не ответили на вопрос о том, считаете ли математику не лучшим инструментом для моделирования реальности в той или иной области? Вот как по мне, так одна проблема, но существенная, сложность для человека, которую (проблему), на мой взгляд, лучше решать улучшением преподавания математики и упрощением (но не в ущерб строгости и выразительности) математики, а не заменой менее формальными инструментами.
Через более понятные обычным людям идиомы — безусловно.
Хорошо. Понятно, что пока мы не умеем строго считать выразительную мощность, мнения относительно оной могут сильно различаться, но тем не менее, есть пример простого аналога, к примеру, монад? Просто на мой взгляд, там и так уже проще некуда, что может быть проще трёх функций с определённым законами? Ну или взять линзы, там вообще просто обобщённая функция, а через одну неё и геттер и сеттер и много что ещё. Это опять же проще, чем какие-то навороченные объекты отдельно с геттерами и сеттерами (хотя вторые проще для понимания, но менее выразительны).
Вот только эта простота — не easy, а simple, поэтому порог входа высокий, но если понижать порог входа, то simpleness потеряется.vintage
14.11.2015 00:29-2Строгость и выразительность не является прерогативой исключительно функциональных языков.
Монады — это костыль, позволяющий спрятать изменяемое состояние под ковёр, притворившись будто его нет. Зачем они в императивном языке — ума не приложу :-)lair
14.11.2015 01:22+4Зачем они в императивном языке — ума не приложу
А вы думаете, что монады — это только IO? Например, монада Maybe сильно упрощает работу с null, монада Try — работу с ошибками (и да, я все еще говорю об императивных языках), да собственно даже удобная работа с коллекциями — это монада.vintage
14.11.2015 20:07А вы думаете, что изменяемое состояние есть только в IO? :-) Все перечисленные монады прячут в себе промежуточный результат вычислений.
lair
14.11.2015 20:23Вот только промежуточный результат вычислений — это не обязательно изменямое состояние. И для его передачи не обязательна монада.
VoidEx
14.11.2015 02:48+2Зачем они в императивном языке — ума не приложу :-)
То-то их тянут в императивные языки. Что LINQ в C#, что for в Scala.
nwalker
14.11.2015 04:39+1Монада — всего лишь абстракция связывания вычислений, способ переопределить «оператор ;», очень удобный синтаксический сахар.
qnikst
14.11.2015 18:31+3> Монады — это костыль, позволяющий спрятать изменяемое состояние под ковёр, притворившись будто его нет.
Я, конечно, не уверен, но мне кажется что перед тем как высказывать экспертное мнение, стоит ознакамливаться с материалом. Тогда будет понятно зачем монады были введены, как используются и чем могут быть заменены и в каких языках.
VoidEx
13.11.2015 11:27Я там выше ответил про аудио-визуальные образы. Я числа представляю обычно в виде циферной их записи — это никак не идёт под раздел «конкретный аудио-визуальный образ», потому что с тем же успехом можно и монады представлять, в виде их записи в мат. нотации, ну или кода. Связи с реальностью будет не меньше.
divan0
13.11.2015 17:31Я числа представляю обычно в виде циферной их записи — это никак не идёт под раздел «конкретный аудио-визуальный образ»
В моем понимании, идет. Когда вы оперируете числами, у вас возбуждаются определенные группы нейронов в визуальной и слуховой коре — а это и есть «аудиовизуальные образы».
vshabanov
13.11.2015 16:53+5Т.е. ты, когда складываешь 2+2 или считаешь сдачу со ста рублей, вместо простого использования заученных с детства правил начинаешь представлять себе яблоки или какие другие «конкретные аудио-визуальные образы»?
И заодно: Обычный человек — это такое устройство, которое не потеряло связь с реальным миром, где есть объекты, у объектов есть состояния, а классы определяются по набору признаков.
Ну расскажи про состояние числа 2, какой у него класс и какие признаки. И насколько это знание в реальном мире поможет тебе посчитать сдачу в магазине.vintage
13.11.2015 23:58-1Именно так, я представляю закорючку «2» написанную чернилами на пергаменте, ещё одну закорючку «2», закорючку "+" и тут же всплывает ассоциативная связь с образом «2+2=4», где я распознаю закорючку «4». Для компьютера всё есть биты, для человека всё есть образы.
potan
13.11.2015 21:21Haskell очень прост и минималистичен. Просто непривычен для воспитанных на императивной парадигме и многословном синтаксисе.
Hokum
12.11.2015 08:56+4Думаю, сложность вызывает функциональное программирование, а не сам язык. Сравнение Хаскеля (или другого функционального языка программирования) с любым другим императивным языком программирования даст похожий результат.
isden
12.11.2015 11:21+3Программировать в функциональном стиле можно почти на любом ЯП.
qnikst
12.11.2015 11:47+3если под функциональным стилем понимается использование map и reduce, и немножко замыканий, то конечно можно.
isden
12.11.2015 12:09Ну лямбды, функции высшего порядка, чистые функции, каррирование, и т.д. — все это хоть в том же JS можно делать. Я уж не говорю про рекурсию.
koldyr
12.11.2015 13:04+1наверное можно, но не придётся ли потратить те же четыре года, чтобы делать это правильно, особенно когда за тобой не приглядыват компилятор?
isden
12.11.2015 13:06Ну не 4, а чуть меньше, но согласен.
Но с другой стороны, на любом языке можно писать такое, что волосы по ночам будут шевелиться во всех местах.
Так что, по моему мнению, уж лучше самому учиться писать хорошо.Hokum
12.11.2015 13:15+1Плохой код будет плох на любом языке и при любом подходе. Не просто переключится с императивного программирования на функциональное (хотя может кому-то и легко) и язык тут не важен.
vintage
12.11.2015 20:31-2То, что эти идиомы впервые появились в функциональных языках и то по необходимости не делает ваш императивный код с использованием этих идиом функциональным ни в коей мере :-)
isden
12.11.2015 21:03+1Суть не в словах, а в том, что за ними стоит. Функциональное программирование — это использование определенного подхода, а не языка при написании кода. Емнип, в том же Хаскеле можно и в императивном стиле писать (сам не видел, каюсь, но рассказывали коллеги).
К слову, лямбда-исчисление изначально не имело никакого отношения к ЯП (их тогда и не было).vintage
12.11.2015 21:16-1ФП — это «программирование без изменения состояния», а не «программирование с использованием замыканий».
isden
12.11.2015 21:17> «программирование с использованием замыканий»
А я где-то это утверждал?vintage
12.11.2015 21:30-1Тут: http://habrahabr.ru/post/270707/#comment_8651791
И для справки: чистая функция — не только не меняет состояние, но и не зависит от изменяемого состояния, чего на JS достичь практически невозможно.isden
12.11.2015 21:49> Тут: habrahabr.ru/post/270707/#comment_8651791
А процитируйте плз, где я сказал, что ФП — это «программирование с использованием замыканий».
> И для справки: чистая функция — не только не меняет состояние, но и не зависит от изменяемого состояния, чего на JS достичь практически невозможно.
Странно, а определение чистой функции говорит нам следующее:
1. является детерминированной
2. не обладает побочными эффектамиkoldyr
12.11.2015 21:59как бы:
является детерминированной = не зависит от внешнего состояния
не обладает побочнвми эффектами = не меняет состояниеisden
12.11.2015 22:04Функция является детерминированной, если для одного и того же набора входных значений она возвращает одинаковый результат. Все.
Побочные эффекты — это модификация глобальных переменных, переданных параметров и т.п.
Вы таки думаете, что этого невозможно достичь хоть на том же питоне или js?vintage
13.11.2015 02:59-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
Ой.lair
13.11.2015 09:36Нет, по описанию этой функции нельзя сказать, детерминированная ли она.
(Привет слабой типизации)vintage
13.11.2015 10:20Недетерменированная функция — это функция, про которую нельзя сказать, что она детерменирована, а не та, которая на каждый вызов возвращает разные значения.
lair
13.11.2015 11:34+2Не вдаваясь в терминологический спор, замечу, что про эту функцию нельзя сказать, что она детерминирована.
vintage
14.11.2015 00:34О том и речь, в JS очень сложно создать чистую функцию, а когда всё же удаётся, результат довольно бесполезен.
nwalker
14.11.2015 04:44Конечно, бесполезен. То-то весь React на этом построен. Хороший, годный react-компонент — это как раз чистая функция State->VDOM, а уж с персистентными структурами данных так и просто сияет.
isden
13.11.2015 09:50Стойте, но мы же передаем разные входные значения (пусть и опосредованно, через переменную).
vintage
13.11.2015 10:31Нет, передаётся один и тот же объект «a» и константа «1».
А то, что результат выполнения опосредованно зависит от глобального состояния — в этом и есть суть недетерминированности.isden
13.11.2015 10:49Ну так этого можно же избежать простыми действиями.
Я согласен, что тот же Хаскел в этом плане способствует (взять ту же концепцию immutable data).
Но это же не значит, что нельзя делать ФП в других языках.vintage
14.11.2015 00:51-1Использование функций высшего порядка не делает ваш императивный код функциональным. Точно так же, как костюм утки не сделает из вас утку. Даже если вы будете правдоподобно крякать :-)
isden
14.11.2015 00:52А что делает код функциональным? Использование хаскеля? Или таки следование неким правилам написания кода?
namespace
12.11.2015 09:04+9Я даже не думал, что кто-то додумается переводить этот горе-вброс. Пщ против хачкеля, lmao.
Ваня, никогда не разочаровываешь.
qnikst
12.11.2015 10:31+7я честно не понимаю сути такого сравнения языков, а тем более приведения в качестве какого-либо аргумента успешные проекты.
Причем на доводы о том, что в языке чего-то не хватает, или что какие-то вещи реализованы неверно, приводятся агрументы, вида
«а мне/успешному проекту, оно не нужно» или «а зато у нас докер». Как будто, что-либо мешает писать на языке успешные продукты,
ну плохой язык, ну и что, вещи практически независимые, в итоге максимальной популярностью обычно начинает пользоваться самый плохой инструмент из достаточных для решения задачи. А успешность написания программ зависит от качества программистов и менеджеров. Особенно аргумент про продукты тоже интересен, я подозреваю, что в NY больше го программистов, чем программистов на Haskell, пишущих публичные продукты, так что результат не сильно удивителен.divan0
12.11.2015 23:05+1А я иначе эту статью вижу. Она про конфликт между понятиями «хороший»/«плохой» между теоретиками и практиками. Когда ты один, ради интереса учишь языки, пытаешься на них что-нибудь «выражать» на синтетических или не очень примерах — у тебя одни представления о том, что будет хорошо, а что нет. Когда же ты попадаешь в «реальный мир» — работаешь с массой других людей, разных компаний, большим количеством чужого кода — начинаешь совсем иначе относиться. И в этой статье как раз хорошо проиллюстрирован вот этот сдвиг (хоть и не окончательный) приоритетов с «теоретика» на «практика» — автор только коммуницируя с другими начал понимать, что возможно, то что ему кажется «объективно хорошим» — не совсем то, что нужно в реальном мире.
qnikst
12.11.2015 23:30+7мне определенно не нравится деление на «теоретиков» и «практиков», это похоже на попытку спрятатья за какую-то ширмочку. Но в целом в «реальном мире» указанные «теоритические» технологии вполне себе успешно используются. Ну и ещё раз скажу, чуть другими словами, хорошесть/плохость языка и применимость или уместность его для конкретного проекта выполняемого конкретной комадной это разные категории.
divan0
12.11.2015 23:46+2Об этом и речь — шкала должна быть в практической уместности и применимости реальными командами на реальных проектах. Go вызывает столько эмоций и его так расхваливают, потому что он даёт возможность быстро и качественно сделать работу при меньших затратах практически в любой команде. Поэтому когда начинают разглагольствовать о теоретических обоснованиях, почему Go плох — это другая категория, другой взгляд вообще на вещи.
Я нередко слышу от гоферов, что они выбрали Go просто потому что быстро позволил писать крутой софт. Если завтра появится ещё более удачное решение, которое будет более практично и будет позволять более быстрее делать такой же качественный результат — не моргнув глазом, перейдут с Го на него. Я и сам абсолютно такого же мнения. И это то, что я называю «практиками».
А «теоретики» (в моей терминологии) — строят какую-то искусственную систему координат, в которую вписывают инструменты, и судят с пеной у рта о языках по ней, часто на много-много лет закрывая себя только в рамках одного языка.
Хотя, возможно, моя терминология не сильно удачная, и можно лучше придумать. Но, я надеюсь, понятно, что в этой модели нет никаких проблем, что языки вроде Хаскеля реально используются в реальных проектах — если это практично (например, команда знает очень хорошо только хаскель — почему нет?), то это хороший выбор.qnikst
13.11.2015 00:07+2В целом согласен.
Кстати, я слышу от хаскелистов то, что они выбирают Haskell, т.к. он дает им возможность качествено и быстро писать софт и легко его поддерживать, при этом у большинства их них в бекграунде есть пачка императивных языков, включая Go. Я правда с Go не знаком настолько, чтобы обсуждать его в данном контексте (практики написания крутых программ). Произошло это т.к. причин продолжать его изучение дальше, чем базовые tutorial-ы, я не увидел. Но даже на этом уровне по сравнению с другими языками той же категории (на мой взгляд python и компания, он выглядит вполне пристойно). Т.е. если я, по какой-то причине, возьмусь писать крутой софт на Go, то я буду страдать от отсуствия возможностей, которые я хотел бы видеть, в языке и с которыми привык работать (те самые теоритические обоснования). В тоже время, замечу, есть достаточно мало областей, где эти причины стали бы для непреодолимой проблемой. как-то так…
Alexeyco
12.11.2015 11:06> в итоге максимальной популярностью обычно начинает пользоваться самый плохой инструмент из достаточных для решения задачи
Выходит, самые лучшие вещи пишутся на самых непопулярных языках и сами не пользуются популярностью? Боже мой, вы открыли нам всем глаза — пойду искать веб-фреймворк на брейнфаке.qnikst
12.11.2015 11:49+1Вы сознательно пропустили часть процитировнной Вами фразы? Бреинфак, не является разумным образом, достаточным для написания веб фреймворка. PHP, например, является, и несмотря на все проблемы языка, особенно в версиях 4.x мы можем видеть множество решений на нём.
Соглашусь, что из моей фразы совершенно непонятно почему иногда наблюдаются мирграции на язык с меньшими проблемами, но это нужно гораздо точнее формулировать фразу или сильно расписывать, а мне лень.Alexeyco
12.11.2015 16:34Причем тут 4 версия PHP? Доступность — вот, что действительно двигает. Создатели того же docker, я уверен, оценивали именно доступность, а не сидели и не выбирали, чего бы им такого придумать, чтобы побольше задниц рвануло. И еще такой параметр как субъективный порог вхождения. Ничего не хочу сказать плохого, но на ruby у меня не смоглось писать, на php я выстрадал… Python завелся вообще легко. Go — тоже оказался достаточно простым. Отсутствие дженериков я лично воспринимаю как несущественную претензию. То есть, это может быть ответом на вопрос «почему ты не выбрал этот язык?», но не показателем качества языка, как по мне. Возможно, в дальнейшем я поменяю свое мнение, но вот сейчас у меня тот самый щенячий восторг неофита от того, что я прогаю, а оно работает. Многословность работы с ошибками вообще не смущает. Тут дело вот, в чем, есть языки, на которых говнокод объективно воспринимается не так ужасно. А есть языки, где надо сначала основательно подумать. И это тоже — субъективный взгляд.
qnikst
12.11.2015 17:39+2версия PHP 4 тут при том, что является примером моему утверждению, а brainfuck нет. Пример был необходим, чтобы больше не возникало идей для передергиваний.
Создателями обычно двигает знание языка, знание похожих языков, наличие готовых библиотек, наличие знаний у команды. Возможно то, что вы называете «субьективной легкостью вхождения». Наприме, если у вас тут есть команда людей на OCaml, а вам нужно написать сложный проект, с большим количеством шаблонного кода, то вы возьмете MetaML, а не go, python или что-либо ещё, на что команда явно потратит больше времени на изучение.
Ещё раз повторюсь, язык не должен быть хорошим, для того чтобы на нём можно было успешно писать, он должен быть достаточным, чтобы на нём ваша команда могла решать поставленные перед вами задачи, а его экосистема должна иметь нужные вам средства для работы (библиотеки/утилиты/документацию/статьи). В го нету очень многого, с точки зрения CS это огромный шаг назад в развитии, никакого анализа решений на рынке, результатов в науке — это плохо? Ну с точки зрения программиста, наверное да, но только когда эти возможности ему нужны. Т.е. в обем-то ответ на половину упрёков (разумных естественно), может быть «да, плохо, решается так (ссылка), ну и что дальше?».
Например, тот же haskell тоже далеко не идеален, метапрограммитование только generic-s (не путать с явовыми) и ужасный TempateHaskell, kinds equal types нету, т.е. никаких там зависимых типов (кроме костылей с синглетонами), function patterns — нет не завезли, и это если не углубляться, причем в разных языках рядом все это есть, но для решения повседневных задач это не нужно.Alexeyco
12.11.2015 17:56И как ваши слова бьются с вашими же словами о том, что самое успешное ПО написано на самом дерьмовом языке. Если, о боже, так много вокруг отличного ПО, написанного на какой-то какашке, то а) это тенденция и б) что-то не так… Причем «что-то не так» — это повод задать себе вопрос «что со мной не так?»
Снова же — только личная точка зрения, ничего больше.
ЗЫ. Опять же, лично моя точка зрения. Вечернее платье, например. Хорошо себе представим платье, яркое, как оно приятно подчеркивает достоинства барышни. А потом вы общаетесь с барышней поближе, и вот утром эта барышня уже без дженериков и без темплейтов, в вашей футболке, пьет кофе и пытается с вами познакомиться. Так же и здесь. Я много раз пытался подступиться к эрлангу, к яве — чего там только нет. Но мне не нужна барышня в вечернем платье каждый день. Сказать по правде, барышня в вечернем платье меня вообще уже больше не интересует — мне надо милую девушку в облегающих шортах, и чтобы не было ничего лишнего. Может быть, в этом дело? Одни языки пытаются быть такими из себя важными, такими надменными. А есть языки, которые, пусть и обладают недостатками, но с ними легко.qnikst
12.11.2015 18:04+2Мне кажется, что вы берёте на себя очень большую смелось переиначивать мои слова и добавлять мне мысли, которых я не думал и не высказывал.
alexrett
12.11.2015 13:28Я что-то вот не понимаю, уже не первая (и явно не последняя) статья о сравнении языков, о том кто лучше, кто хуже, у кого какие проблемы и т.д.
А вот почему микроскоп лучше молотка? и тем и другим можно забивать гвозди, если того требует ситуация и задача. Но это далеко не значит, что молотком можно изучать микроорганизмы.
Проблемы есть у всех яп. Нет и не будет идеального языка программирования, просто потому что «человеки» никогда не придут к единому мнению, всегда кто-то будет против чего-то. И поэтому выбирать язык для создания того или иного проекта наверное имеет смысл не по тому на сколько «острое у него лезвие топора», а на сколько дешево\быстро\качественно\расширяемо\затратно создать прототип и выкинуть на рынок.
Вот php — плохой язык, так все говорят повально. Он создан умирать, — говорят в каждом подобном топике. Тем не менее на нем сделано уйма полезных и хороших продуктов. C# тоже многим не нравится, Python также находит своих недоброжелателей, но как-то это не меняет предыдущего высказывания.
Так может уже перестать сравнивать теплое с мягким или жидкое с соленым? Я бы вот с радостью узнал в каких областях тот или иной язык лучше применять и почему. Да, знать минусы надо и хорошо, что о них рассказывается. Но полемика ради полемики же во всем остальном, разве нет?
Ramires
12.11.2015 13:56+3Он создан умирать, — говорят в каждом подобном топике
Эта фраза не означает, что язык должен умереть и исчезнуть.
Это сказано в том смысле, что на PHP не стоит делать программы, крутящиеся в вечном цикле. Он рассчитан на инициализацию, обработку запроса, завершение.alexrett
12.11.2015 15:03+1Корни высказывания вполне понятны, а вот смысл вкладываемый в нее многими ораторами, скорее всего, не так однозначен.
sferrka
12.11.2015 14:00Ну вообще-то в статье четко сказано, что на haskell вы будете гораздо продуктивнее, а начит быстрее выбросите прототип на рынок и приводятся аргументы в виде недостатков go. Области применения у языков общего назначения (в отличии от php) тоже одинаковые, это сравнение одного универсального молотка с другим.
alexrett
12.11.2015 15:08Что-то мне не кажется, что 4 года потраченного на изучения haskell будут продуктивнее быстрого старта с go. В общем-то я ничего не имею против, но было бы круто увидеть четкое высказыванием например — «изучите {lang} потратив на него N часов и вы получите следующие преимущества, в отличии от [...] потому как имеются такие-то и такие-то преимущества и минусы.» И вот на мой взгляд это куда объективнее при сравнении двух молотков, а статья, лично у меня, вызывает скорее ощущение сравнение микроскопа с молотком. Хотя я могу глубоко заблуждаться и возможно совершенно не понял посыл в статье.
koldyr
12.11.2015 18:33на хаскеле было бы продуктивнее, если бы все писали на хаскеле.
всетаки большая часть по это скомбинированные примитивы.
классическая проблема курицы или яйца, помноженная на высокий порог входа.
lega
12.11.2015 14:05И при всём этом, Go оказывается гораздо более популярным, чем Хаскель, если верить GitHub. Внезапно, на Go уже написано так много потрясающих проектов, вроде Docker, InfluxDB, etcd, consul, prometheus, packer и многих других.
У го есть проблемы, но он создан что-бы разрабатывать продукты (своей нишы), а для чего создан хаскель?qnikst
12.11.2015 14:19+5Haskell создан для того, чтобы был основной язык для изучения свойств ленивых функциональных языков. В то время на этой нише не было ни одного подобного языка, а запрос был, впрочем за последние 20 лет ситуация не изменилась.
То, что на Haskell оказывается можно ещё и код писать, это счастливая случайность. И за последние годы Haskell экосистема заметно продвинулась в данном направлении.divan0
12.11.2015 23:07То, что на Haskell оказывается можно ещё и код писать, это счастливая случайность.
Это реально так или просто излишнее утрирование?qnikst
12.11.2015 23:18+9Скорее реально, лучше распишу полностью, чтобы не было недоговоренного, или если что меня бы поправили. Изначально Haskell академический язык и песочница для различных исследований и проверки концепций, до ~95 года (т.е. около 5 лет существования языка) в нём нельзя было делать полноценного IO и программа это была или подача строки на вход и оно выдавала строку на вывод, или чуть-чуть расширенный набор примитивов. Называть такой язык не исследовательским языком тяжело и языком на котором можно писать программы тяжело. Однако среди авторов языка и тех кто с ним работал были и люди, которые двигали его в сторону, где его использование в общем случае было бы возможно. В районе ghc-6.12 уже стало достаточно пристойно, хотя и все равно было много вопросов. В общем-то языком, на котором можно писать полезные программы он стал не так и давно, и в планах изначально этого не было, просто так получилось.
greabock
[sarcasm]
Хороший материал. Надо бы еще assembler с javascript сравнить…
[/sarcasm]
divan0
Имхо, в статье не сравниваются языки.
Да и haskell vs go совсем не то же самое, что asm vs js. Так что такой себе сарказм )