Я себя индусом не считаю. Но я объективно смотрю на реальность и вижу в ней очень простой факт — миллионы индусов реально (и некоторые — много) зарабатывают на жизнь программированием. И при этом все эти необъятные орды конкурируют и с хаскелистами и со всеми остальными, и в конкуренции не проигрывают. А вот хаскелистов (функциональщиков, в общем виде) очень мало. Если поделить индусов на хаскелистов, получим по сути деление на ноль с бесконечно большим результатом в пользу индусов. И это всё — объективная реальность, с которой стоит считаться.
>> Вот вы в своем языке знаете, у чего больше приоритет: у плюсика, скобочек или знака умножения?
В моём языке нет оператора $, а кроме того нет такой важности приоритетов, потому что в моём языке активно используются скобки. Да, больше скобок — длиннее текст, но в данном случае длинна помогает пониманию. А в вашем случае вы так и не пояснили, почему же на самом деле оператор $ выполняет такую интересную функцию по устранению скобок, что означает — вы не поняли, как он работает, значит не сумеете его использовать в других места. Это и есть минус, который тянут за собой приоритеты без скобок.
>> Ну то есть я в полтора раза быстрее чем на го, неэффективно используя язык.
Да, вы неэффективно использовали язык. А в полтора раза быстрее лишь потому, что вам повезло — вы наткнулись на библиотеку, которая за вас всё сделала. Индусы тоже так умеют. И да, хаскель они бы именно так изучали — нашли бы в гугле пример и воткнули в программу, потом попробовали, если не работает — побежали бы на форум и начали спрашивать — почему? Ну и так в цикле написали бы нечто, может и ужасное, но выполняющее целевую задачу. А вот если шаг влево/вправо от узкой задачи — у них всё будет не так, криво да косо. Потому что копипаста до добра не доводит. А вменяемый специалист сначала понимает суть проблемы, потом выбирает подходящий инструмент, которых хорошо знает, и в результате всё у него получается красиво да хорошо, просто потому, что он абсолютно всё в процессе понимает, в отличии от копипастящего индуса.
>> То что вы не разделяете интерфейс как элемент ООП и интерфейс как набор публичных АПИ о многом говорит.
Не знаю, на основании чего сделан такой вывод. И тем более, не знаю, о чём это говорит.
>> Потому что я могу написать такую функцию на сишарпе
То есть если быть проще и говорить прямо — вы считаете, что чистота от сторонних эффектов — это адский плюс. Но речь-то шла о поиске по сигнатуре и вообще о некой мифической ценности именно сигнатуры. Возникает интересный вопрос — как ценность сигнатуры вдруг связалась со сторонними эффектами?
>> Это какой-то призыв «спервадобейся» и «ктотытакойчтобымнеговорить»
Нет, это призыв посмотреть правде в глаза. А правда простая — индусы реально конкурентоспособны. Вы будете спорить? Ну тогда съездите в Индию, посчитайте их там по головам — будет очень много новых открытий.
>> Вместо того, чтобы изучать 101ую библиотеу для того чтобы делать то же самое, что и другие 100, но теперь с модной финтифлюшкой, можно попробовать решить проблему принципиально.
Так я не увидел принципиального решения проблемы. Я же говорил — вы нашли (и это просто удача) подходящую библиотеку, вот и вся принципиальность решения.
>> только это не работает дальше одноразовых скриптов до пятисот строк.
Ну почему же, индусы пишут очень большие программы, и тому есть бесконечное количество примеров. Вот наверняка ваш телефон имеет на борту гугловый ведроид, так там большая часть кода — от индусов (хотя не все они из Индии).
>> Что если я вам скажу, что компилятор при желании может проверить все ошибки в вашей программе, включая логические?
Я вам не поверю.
>> Ну если вы хотите на го написать интерпретатор хаскелля то милости просим, теоретически это конечно возможно.
Нет, там проблема решается гораздо проще.
>> Вообще-то мы говорили Linq2Objects, там вообще никаким SQL не пахнет. Вы же сказали про императивные циклы, вот я привел пример того, как языке вместо них пишут запросы. Вы, это, сжудения не подменяйте.
Поясняю — LINQ, это расширение декларативных запросов из области реляционных баз на область любых множеств, поэтому SQL — основа того, что получилось в LINQ. Ну а императивные циклы есть способ обработки всё тех же множеств, поэтому если речь идёт о БД, там эту часто повторяющуюся потребность выделили и создали на этой основе язык SQL, после чего (лет 50 спустя) некто наконец решился создать аналог с чуть более широкой областью применения (LINQ). Поэтому я вам и ответил про SQL.
>> Вот я придумал сделать сортировку, которая не зависит от типа объектов (только чтобы он сравниваться умел), а язык, собака, мне не дает его написать
Императивные языки давно и качественно решают эту проблему, и вы это должны отлично знать на примере C#. Ну а в го я не спец, поэтому по нему я вам не подскажу.
>> Это про хаскель из каждого утюга вещают и запросы в гугл подменяют?
А про го разве вещают? Нет, там всё проще — вешают объявление, з/п программиста на го — 200к$, и всё, далее остаётся лишь говорить о чьей-то неконкурентоспособности.
>> Так ваш компромисс это исключительно «хуяк хуяк и впродакшн». Такой себе компромисс, должен сказать.
Я не спорю, любую мысль можно извратить, но компромисс — это не крайность, а потому вы меня просто неправильно поняли, либо понять не захотели.
>> Ненастоящий шотландец
Опять нет. Я вам снова повторю — если кто-то сделал что-то в 5 раз быстрее, значит тот, кто делал до него — клинический дебил, либо ему было плевать на результат (а значит на результат было плевать и всем его начальникам по цепочке до самого верха).
>> вещи вроде паттерн матчинга, лямбд, query-language в языках и асинк-авейт это Early majority, а то что я тут рассказываю — Early adopters. А у человека с опытом всегда преимущество
Точно. У человека с опытом есть большое преимущество — он может расслабиться и лениво поглядывать на безумства Early adopters, ибо когда они наконец нарезвятся вдоволь, можно будет спокойно спуститься с небес и… отыметь всё стадо получить все ништяки.
Но проблема в том, что пока винигрет в сообществе функционалов не устаканился, а это означает, что данная технология ещё молода и не даёт должного эффекта в реальной жизни. Поэтому заниматься активно этой пляской с бубнами — тратить время на развитие недоразвитого организма. Только вот конкретно мне пока не хочется тратить много времени на этого детёныша, просто потому, что для меня есть более интересные темы, а в данной — да, похоже есть кое какие перспективы, но пока они где-то за облаками.
Это важно для мелкого бизнеса, поэтому вас там и удивили детской считалкой. А крупный, и даже средний — им всем плевать на лояльность. Потому что никуда вы от них не денетесь. Ведь если предпочли магазин у дома супермаркету, то как вас не задабривай в службе поддержки (куда вы за всю жизнь один раз — и то вряд ли позвоните), вы всё равно пойдёте в магазин у дома.
В целом же, чисто статистически, требование к службе поддержки одно — она должна быть примерно как у конкурентов. И всё. Если лучше — это почти ничего не изменит. И даже если хуже — тоже не сказать, что бы страшно просядет бизнес. Поэтому её поддерживают в примерно близком к среднему по больнице состоянии, ну и более на неё не отвлекаются.
Вот вы в своём коде использовали значок $, а почему? Знаете?
>> Знать все библиотечные функции не обязательно, достаточно уметь сформулировать вопрос в гугл. А то и в хугл.
Ну так вы слона не продадите. Я тоже могу сказать, что знаю любой язык, но со словарём, ведь делов-то — вбил в гугл-транслейт текст и почти всё понял!
Эффективно использовать инструмент, постоянно ползая по интернету — невозможно.
>> чтобы знать что что-то работает нужно иметь возможность судить об этом по интерфейсу, а не по реализации
Во первых, интерфейсы есть почти во всех императивных языках. Чем в этом плане лучше хаскель? Во вторых, реализация хоть сколько-нибудь сложного алгоритма всегда предполагает знание её пользователем набора ограничений, вне которых алгоритм не работает (или работает криво). Если вы ещё не изучили, что такое возведение в квадрат — какой смысл говорить о функции, которая возводит в квадрат? Даже если весь этот текст содержится в её названии.
>> >> А вот хугл это очень крутая штука, я тут потыкал недавно
>> Достаточно просто сделать поиск по сигнатуре (a -> Bool) -> [a] -> [a]
>> С императивными функциями () -> () так не выйдет, увы.
Почему не выйдет с императивом? Например: (int[]) -> (int[]). Но интересно, а если функция просто переставляет пару значений в массиве, то как вы её отличите от сортировки?
>> Если человек потратил время чтобы изучить его возможности он напишет так же быстро, как и на го
Но он так же потратит меньше времени на изучение го, значит суммарные затраты времени меньше.
>> Я уже не раз говорил, что я предпочту потратить день на изучение фичи, которая будет мне экономить одну минуту каждый день до конца жизни.
Это хорошая максима, но исключительно для тех, у кого времени — вагон. В реальной жизни (если время всё-таки ограничено), приходится находить компромисс. И вот сообщество функциональных программистов здесь склоняется к максимизации времени на долговременно полезные затраты, а в реальной жизни с такой ориентацией быстро становишься неконкурентоспособен.
Я же говорил — будь у меня куча лишнего времени, я бы обязательно много чего поизучал бы. Но даже когда вдруг время появляется, то оказывается, то «много чего» за раз не получается, приходится расставлять приоритеты, а потом находить способ не затягивать с первым выбранным предметом, ибо всё на свете можно копать до бесконечности, но тогда ведь на остальные темы времени никогда не будет. Поэтому компромисс обязателен. Как минимум для тех, кто хочет получить от жизни больше. Но да, можно отказаться от всего остального и заняться самосовершенствованием в хаскеле. Только мне это не кажется полезным.
>> на протяжении всего этого года нам могли бы объяснить принцип, и мы бы для любых фигур могли бы считать, а не только для «одобренных минобром»
Ну здесь же вы опять в сторону индусов уходите, хотя их образ действий критикуете. То есть объяснить принцип вам могли бы, но это был бы лишь некий магический и непонятно как работающий способ. А что бы его понять — нужно пройти курс высшей математики и изучить пределы, производные, интегрирование, плюс ещё что-то там (не помню, давно учил). И если вы предпочитаете получить работающий способ здесь и сейчас, то вы идёте строго по пути индусов. Ну и при этом не будете понимать, как вам расширить круг приложений для своего инструмента, потому что просто не понимаете, как он работает (ведь не изучали высшую математику).
>> Поймите, что вся суть в том, чтобы компилятор ловил ошибки.
Поймите, что уровень, когда вся сложность ограничивается тем, что может компилятор, совершенно недостаточен для вменяемой разработки ПО. Такой подход люди тупо заменяют генерацией кода.
>> Ниже объяснялось, почему не получится это сделать в го. Ни без генериков, ни с ними.
То есть вы поверили, что некий алгоритм в принципе не реализуем на языке, реализующем машину Тьюринга, но при этом отлично реализуем на другом языке, который тоже реализует машину Тьюринга?
>> Спросите у сишарпистов, что понятнее, императивный код на циклах или декларативный на LINQ.
Вы путаете ниши. Есть, например, SQL (более распространённый аналог LINQ). И никто в здравом уме не пишет в императивных языках всё то, что можно сделать на SQL. Поэтому ваш пример абсолютно некорректен.
>> Если для го приличный код можно выдавать через месяц, то на хаскелле через 2-3. На примере того же Rust я слышал именно такую статистику. Вопрос в том, что у вас нет ограничения на потолок.
Ограничивает не язык, а умение придумать правильный алгоритм. Ну а инструмент — он и в африке инструмент. То есть он должен быть удобным, это да, но превозносить удобства до небес, даже заявляя, что «с этим инструментом можно сделать то, чего ни один другой (императивный) инструмент не может» — это неправильно.
>> Я не буду выбирать плохой инструмент только потому, что он модный
Хаскель как раз — модный. То есть продуктивность в реальной жизни он не обеспечивает, но создаёт иллюзию «последнего писка технологичности».
>> Времени вообще никогда не хватает
Картинка весёлая :)
Но про компромисс и при её создании забыли.
>> Мы недавно переписали сервис с джавы на хаскель, и выиграли в 5 раз по памяти и в 10 по производительности
Значит писали сервис индусы. Если переписать сервис с хаскеля на Java, но не по индуйски, то вы ещё больше сэкономите.
>> Что касается экосистемы, то всегда есть Scala
Да, есть. Но всё же пока востребован императив, поэтому я на «тёмной стороне» силы. Вот победит функциональщина, докажет продуктивность в массовой разработке — я к вам обязательно присоединюсь :)
А пока — пусть фанаты функций готовят дорогу для будущего счастья, может даже когда-то у них получится. Я же поигрался и не увидел серебряных пуль и прочего вундерваффе.
>> вот только это увеличивает вероятность багов и более того распространяет эту заразу в клиентский код
Опять не совсем правильный подход. Эволюция ведь, как ни странно, всё ещё работает, то есть отбирает наиболее адаптированных к условиям обитания. Поэтому возникает интересный вопрос — а почему в нынешних условиях процветают индусы? А функциональные языки задвинуты куда-то в академии.
>> Вы читаете текст, который комментируете? Советую почитать про tagless final encoding чтобы узнать о том, как много информации может предоставлять сигнатура функции.
Я читаю текст, который комментирую. А вы читаете? В моём сообщении было про неверно интерпретируемое название. И заметьте — это ещё цветочки. То есть что для полноты понимания вам стоит отказаться от всей документации и попробовать понимать чужой код по сигнатурам.
>> map-reduce (hadoop, spark), erlang, aws lambda… как жаль что «сторонники функционального подхода» продолжают тащить в продакшен эту свою функциональщину
Для справки — aws lambda работает с разными языками, поэтому выделение из них исключительно функциональных говорит о вашей исключительной предвзятости.
Если бы всё было так шоколадно, то индусы давно бы сдулись и над всем миром парили бы сплошные хаскелисты. Но что-то пошло не так и почему-то над миром парят всё больше сплошные индусы.
Проблема не в state-of-the-art. Проблема в необходимости зарабатывать. Вокруг этого построена жизнь, поэтому state-of-the-art можно интересоваться, но если в конкуренции с индусами вы начинаете проигрывать — время задуматься о земном.
Сложно представить себе выгоду от наличия качественной службы поддержки для массовых клиентов. Вот для ВИП-ов — пожалуйста, там всё крутится именно вокруг их персонального облизывания. А для обычной серой массы — ну зачем это бизнесу?
Вам кажется, что вы не обычная серая масса? Ну ладно, я не буду вас разочаровывать. Но бизнес всё решает без учёта и моего и вашего мнения. Поэтому, как мне кажется, это просто объективная реальность, данная нам в ощущениях — мы не можем купить хороший сервис. А раз не можем, то на что жаловаться? И да, кто виноват, что мы не можем купить хороший сервис? Это тоже довольно важный вопрос. Потому что качественный ответ на него может изменить всё общество. А без изменения — мы так и останемся неважной для бизнеса серой массой.
>> Ну так все правильно, каждая строчка понятна, а при их композиции произошла фигня. Потому что строчек много, и комбинаторный взрыв происходит очень неприятный.
Во первых, это подтверждает очевидную истину — не зная в деталях объект приложения усилий, можно нагородить ерунду. Поэтому здесь ничего удивительного нет, кроме одного момента — почему вы удивляетесь, что не можете понять смысл целого, когда не знаете деталей?
Во вторых, разбираясь с хаскелем, в голове не заучившего наизусть все приоритеты и все библиотечные функции программиста, происходит тот же самый комбинаторный взрыв. Но структура хаскель-программ каким-то образом способствует вселению уверенности в происходящем в голову, вот например вас, не разбирающегося в приоритетах и сути происходящего в программе. При этом, как было замечено ранее, незнание деталей может привести к проблемам. А уверенность в происходящем, без знания деталей, как раз очень способствует наступанию на разные грабли.
Вообще, когда я не понимаю, что происходит при выполнении программы, меня это напрягает. Я оказываюсь в ситуации, когда должен полагаться на волю случая — а вдруг там внутри всё само как-то правильно сложится? И да, хаскель содержит встроенные средства контроля разных косяков с типами, а так же сама структура вызовов кое-что подправляет за программиста, но ведь это всё — абсолютно неявно, неочевидно и непонятно, ровно до тех пор, пока вы не вызубрите все приоритеты и все используемые функции. А что бы вызубрить все функции стандартных библиотек, надо потратить немало времени. Без зазубривания же вы не сможет понять чужой код. Точнее — по вашему, как вы выше сообразили без понимания происходящего внутри, представить себе нечто вполне возможно, и даже хаскель поможет вам своими приятными качествами, но тем не менее — вы по прежнему не понимаете, что происходит внутри, а значит по прежнему не понимаете, где находится проблема, если после запуска программа выдаст не то, что вы ожидали. И как только такая неожиданность случится — всё, полностью и дословно повторится история с го, когда по частям вам кажется, что всё понятно, а в целом — ничего не работает. А всё из-за чего? Из-за отсутствия понимания происходящего внутри. А для получения такого понимания вам нужно потратить много времени на зазубривание приоритетов и хотя бы функций из стандартной библиотеки (а их там несколько десятков, плюс десяток занимательных типов, и это без монад и прочего IO). Вот в этом и проблема хаскеля — он не предназначен для тех, кому нужен простой и быстрый результат. А это как раз все те индусы. И как бы вы не возражали, но «индусов» на земле на порядки больше, чем тех, кто готов потратить время на спокойное изучение хаскеля, на зазубривание приоритетов и изучения всех библиотечных типов и функций. Это аналогично высшему образованию — нужно пройти высшую математику, и лишь потом станет понятно, почему теория автоматического управления целевым объектом действительно даёт правильный результат. Но вспомним — сколько людей так и остаются без высшего образования? Вот такой же процент не будет готов и к изучению хаскеля. А вот го они осилят легко. Потому что там сразу ясно, что происходит. Ну а комбинаторная сложность комплексных явлений, будь то текст программы или что угодно ещё, всегда высокая. И в хаскеле с ней бороться невозможно без понимания всех функций, типов, приоритетов. Хотя да, можно полагаться на удачу — запустил и оно как-то само всё сделало. Но это не наш метод. Это скорее опять к индусам, которые понадёргают из примерчиков составляющих и получают нечто, вроде даже работающее, но все проблемы, кроме самых очевидных, индусы никогда не вылавливают, и не важно, на хаскеле они это делают или на го. Но го они хотя бы способны понять. А вот хаскель — практически никогда не поймут до уровня, который позволит им разобраться в сложных проблемах.
>> Мне кажется, что такой библиотеки просто в принципе нет, по крайней мере я не представляю, как её создать с теми возможностями, что дает Go.
Если вы в курсе, что такое дженерики, то всё вы легко поймёте. На крайний случай — есть просто тип Object, плюс интроспекция — вот вам и рецепт для повторения. То есть при минимальном желании библиотеку написать вполне возможно. Ну а возражения других участников о якобы невозможности такого чуда — оставим на их совести.
И о совести. Почему-то сторонники хаскеля всегда наиболее воинственно отстаивают преимущества своего любимого чуда. И при этом игнорируют любые указания на недостатки. Вот почему бы это?
>> язык, где по сигнатуре можно понять всё, что происходит внутри (например, есть вывод на экран/запись в БД/… или нет) очень экономит это самое время
Нельзя ничего понять по сигнатуре, если не знаешь алгоритма внутри вызываемой функции. Можно строить предположения, можно догадываться, можно гадать на кофейной гуще, но полноценно понять — нельзя. Назовём функцию вычисления квадрата cube, вы по её сигнатуре поймёте, что с ней что-то не так?
>> мне кажется, что 15 строк прочитать проще, чем 60
Опять — вам кажется. В одну строку можно вытянуть выражения почти на любом языке, но понятней от этого не становится. Та же обработка в циклах на императивных языках часто гораздо нагляднее, нежели то же самое, но с рекурсивными вызовами, без которых в принципе нельзя сделать что-то вменяемое на функциональных языках. И да, в императиве при этом строк будет больше. Но понятность-то будет лучше!
>> Для человека с хотя бы годом опыта работы в любом несистемном языке не будет никаких проблем с изучением хаскелля
Вопрос не в возможности изучения, а в скорости. Индус будет изучать лет 5 (может утрирую, но не сильно). А го изучит параллельно с работой, даже не заметит. Есть разница?
>> Ну а быть или не быть «обычным индусом» каждый человек пусть решает сам. Мне кажется, что разработчики достойны лучшего и должны ценить своё время
Проблема не в самооценке, а в объективно существующей потребности. Потребность простая — надо много и быстро. А индусы на хаскеле — не способны ни много, ни быстро. И как бы вы не решали, кем хотите быть, проблема от этого никуда не денется.
И да, разработчики, которые ценят своё время, как раз очень озабочены затратами этого самого времени на зазубривание хаскеля хотя бы на уровне стандартного синтаксиса и Prelude. То есть если времени девать некуда — ну тогда ОК, можно заниматься хаскелем. А если есть актуальные задачи?
Вообще, пришла в голову простая мысль — сторонники функционального подхода реально не знают, что такое требования жизни. То есть в академиях и прочих неспешно грызущих гранит науки заведениях действительно можно годами ваять на хаскеле примитивный софт, потом его вылизывать, совершенствовать и т.д. И в конце получить нечто, от чего можно выпячивать губу, мол вон что мы сотворили! Но как коснёшься реального применения (то есть в реальной жизни), то сразу вылазят косяки хоть и достаточно общего подхода, но далеко не универсального. Возьмите стандартный (или просто распространённый, я тут не возьмусь вешать ярлыки) ORM на хаскеле — концепт изначально ориентирован на манипуляцию SQL, а в реальной жизни акцент смещается на манипуляцию с результатами работы SQL. И это сильно не одно и то же. Хотя да, подход в хаскельном варианте солидный, обобщённый и т.д. Но пользоваться — неудобно. Может для мелких академических задач это нормально, но для реальной жизни — ну не то, просто неудобно.
В целом я бы повозился с тем же хаскелем побольше, но вот реально — а что толку? Куда я его прикручу с его неудобными ORM-ами и прочим? Народ давно попробовал и сделал вывод — для enterprise разработки оно реально неудобно. Куча гемороя с поддержкой состояния, малое количество библиотек и неудобство существующих (хотя хаскелисты здесь будут долго кидаться гнилыми помидорами).
>> Не понимаю, я же это прямо написал в самой статье, в чем собственно и посыл
Я же специально выделил часть вашего текста:
я точно знаю что происходит на каждой строчке программы
>> Так я только рад буду, если вы покажете какую-нибудь библиотеку на го, которая позволит сделать все то же самое.
Так суть-то не в показе библиотеки, а в сравнении двух языков на основании нахождения для одного из них уменьшающего сложность решения. Простая случайность (нагуглилось нужное) приводит к выводу о порочности всего языка. Вот про это я и говорил.
>> Моя грубая оценка: опытный го-разработчик написал бы минут за 5, а опытный хаскеллист минуты за три.
Пусть даже так (хотя не факт), но что это меняет? В любой серьёзной разработке собственно написание кода — это малая часть работы. И разница 3-5 минут вообще ничего не решает. А решает, например, лёгкость освоения языка, ибо нужно много программистов, а где их взять? И вот в случае хаскеля простота обучения, скажем прямо, так себе. А в случае го — всё доступно. Именно поэтому гуглы и придумали го, ибо им нужны миллионы индусов, которые задёшево и быстро освоят новый язык. Представьте себе, сколько времени займёт освоение хаскеля обычным индусом (из тех самых миллионов). Представили? Вот поэтому го идёт в массы, а хаскель тихо курит бамбук в академической среде.
ЗЫ. Это всё не спора ради. Просто замечания по смыслу текста. Надеюсь на некоторое дополнение к статье с осмыслением данных замечаний. Хотя с другой стороны — количество просмотров упадёт буквально через пару дней, так что может и не стоит заморачиваться с дописанием.
Да, в этой сфере нас ждут потрясающие перспективы (в самом прямом смысле) — всю душу вытрясут.
Вообще, полноценный ИИ действительно очень близок. И естественно, если он будет в руках нынешних хозяев мира, то… Видимо, нам всем в таком мире будет отведено место лишь около известного по отдельным кинофильмам оборудования.
>> И в го получается диаметрально противоположенная с хаскеллем ситуация: я точно знаю что происходит на каждой строчке программы, но не понимаю почему она дедлочится.
Она дедлочится потому, что автор данного текста на самом деле не понимает того, что происходит в программе, хотя и заявляет, что понимает каждую строчку. Я надеюсь, что автор честно сам себе в этом признается.
Следующий момент — автор скачал хаскелевскую библиотеку, которая берёт на себя все проблемы с распараллеливанием, затем вставил её в свой код на хаскеле, потом не нашёл аналога на го и начал изобретать велосипед «своими руками», после чего изобретение «не поехало». И какой из этого делается вывод? Ну конечно же — го отстой, а хаскель — это круто.
Не наличие библиотеки против непонимания работы го, а именно го виноват во всём.
Автор, может вы передумаете?
И наконец, на С# код написан много быстрее, чем на хаскеле. Из минусов — некоторая кажущаяся объёмность переделки кода под новую структуру. Но разве мы постоянно меняем структуры в программе? Вроде нет. Тогда каков вес этого минуса? И каков вес плюса, позволившего очень быстро написать решение на привычном языке?
В целом мне тоже го не нравится, но всё же в данном тексте вижу необъективность, а потому показываю пальцем. Сорри, автор, минусуй, может и не проиграешь.
>> Именно разработчик отвечает за соответствие требованиям. И если заказчик хочет чего-то нарушающего, разработчик об этом должен знать и предупредить.
Гугл разработал сервис распространения приложений, значит он «отвечает за соответствие требованиям. И если заказчик хочет чего-то нарушающего, разработчик об этом должен знать и предупредить». И да, гугл предупреждает, но примерно так — приложение заблокировано, дальше думай сам.
Как вы думаете, гугл должен выполнять ваши правила? А если нет, то почему другой разработчик должен?
Забота о прибыли, разумеется, а не о пользователях. И на такую заботу самым прямым образом влияют разного рода государственные органы, от законодателей до исполнителей типа того же РКН. Ну а пользователи — просто некая абстрактная целевая ниша, куда нужно пооптимальнее вписать свои потребности.
>> Малый бизнес — основа. Из малого вырастает средний. А вы же хотите все монополизировать
Малый бизнес = ужасно неэффективная потеря времени. Если вы слыхали про эффект масштаба, то наверняка поймёте, что с малым бизнесом не так. Единственный его плюс — гибкость. Но гибкость эта проявляется лишь на фоне стандартного подхода к управлению в больших конторах. Когда же контора целенаправленно создаёт гибкую систему, то никакой малый бизнес рядом уже стоять не может. Сравните разного рода конструкторы для квалифицированных пользователей с возможностями малого бизнеса в таких сферах. Например какие-нибудь математические или статистические программы, с которыми работают конечные пользователи. Вот где здесь место малому бизнесу? Зачем там кто-то лишний?
Правда пока что есть конструкторы для неквалифицированных пользователей (типа 1С), но по сути это тот же вариант, что и показанный выше, поскольку эти конструкторы ориентированы на профессионально занимающихся их использование. То есть все эти настройщики 1С — это как раз и есть те самые потребители, под которых заточены конструкторы. Ну а бухгалтера просто примут всё то, что им согласится купить начальство. В итоге настройщики 1С работают точно так же, как и обычные наёмные работники, но тешат себя надеждой на некий «успех», которого обычно не бывает. Но эффективность такой работы низкая. Прямое сопровождение от производителя было бы эффективнее, но с этой стороны уже стоит неумение построить гибкую систему такого сопровождения. Точнее она построена, но в максимально людоедском варианте, только такой вариант всегда приводит к заявлениям типа «Проблема актуальна только для России/СНГ», хотя на самом деле проблема актуальна для всех, кто решил строить людоедскую систему, но такую причину обычно люди видеть не хотят (даже не знаю, с чего у них такая святая вера в идеальность закона джунглей).
Любое сопровождение в итоге превращается в постоянную работу, хоть и оформляется не по ТК. Фрилансер здесь по сути даёт возможность работодателю перебирать людей и быстро отказываться от неугодных, а после выбора менять человека гораздо сложнее и обычно он долго по сути работает «на пол ставки».
Ну и конечно, некие мелкие задачи по сопровождению мелкого же бизнеса — ну кому это интересно? Да, тем, кто работает за обычную з/п. Но с точки зрения добавленной стоимости — что это за деньги? Это почти невидимые в масштабах экономики суммы. То есть основную добавленную стоимость создают коллективы. А одиночек вот так используют лишь ради возможности игнорировать ТК. Но что это значит для фрилансера? Это значит, что он реально дешевле наёмного работника.
В моём языке нет оператора $, а кроме того нет такой важности приоритетов, потому что в моём языке активно используются скобки. Да, больше скобок — длиннее текст, но в данном случае длинна помогает пониманию. А в вашем случае вы так и не пояснили, почему же на самом деле оператор $ выполняет такую интересную функцию по устранению скобок, что означает — вы не поняли, как он работает, значит не сумеете его использовать в других места. Это и есть минус, который тянут за собой приоритеты без скобок.
>> Ну то есть я в полтора раза быстрее чем на го, неэффективно используя язык.
Да, вы неэффективно использовали язык. А в полтора раза быстрее лишь потому, что вам повезло — вы наткнулись на библиотеку, которая за вас всё сделала. Индусы тоже так умеют. И да, хаскель они бы именно так изучали — нашли бы в гугле пример и воткнули в программу, потом попробовали, если не работает — побежали бы на форум и начали спрашивать — почему? Ну и так в цикле написали бы нечто, может и ужасное, но выполняющее целевую задачу. А вот если шаг влево/вправо от узкой задачи — у них всё будет не так, криво да косо. Потому что копипаста до добра не доводит. А вменяемый специалист сначала понимает суть проблемы, потом выбирает подходящий инструмент, которых хорошо знает, и в результате всё у него получается красиво да хорошо, просто потому, что он абсолютно всё в процессе понимает, в отличии от копипастящего индуса.
>> То что вы не разделяете интерфейс как элемент ООП и интерфейс как набор публичных АПИ о многом говорит.
Не знаю, на основании чего сделан такой вывод. И тем более, не знаю, о чём это говорит.
>> Потому что я могу написать такую функцию на сишарпе
То есть если быть проще и говорить прямо — вы считаете, что чистота от сторонних эффектов — это адский плюс. Но речь-то шла о поиске по сигнатуре и вообще о некой мифической ценности именно сигнатуры. Возникает интересный вопрос — как ценность сигнатуры вдруг связалась со сторонними эффектами?
>> Это какой-то призыв «спервадобейся» и «ктотытакойчтобымнеговорить»
Нет, это призыв посмотреть правде в глаза. А правда простая — индусы реально конкурентоспособны. Вы будете спорить? Ну тогда съездите в Индию, посчитайте их там по головам — будет очень много новых открытий.
>> Вместо того, чтобы изучать 101ую библиотеу для того чтобы делать то же самое, что и другие 100, но теперь с модной финтифлюшкой, можно попробовать решить проблему принципиально.
Так я не увидел принципиального решения проблемы. Я же говорил — вы нашли (и это просто удача) подходящую библиотеку, вот и вся принципиальность решения.
>> только это не работает дальше одноразовых скриптов до пятисот строк.
Ну почему же, индусы пишут очень большие программы, и тому есть бесконечное количество примеров. Вот наверняка ваш телефон имеет на борту гугловый ведроид, так там большая часть кода — от индусов (хотя не все они из Индии).
>> Что если я вам скажу, что компилятор при желании может проверить все ошибки в вашей программе, включая логические?
Я вам не поверю.
>> Ну если вы хотите на го написать интерпретатор хаскелля то милости просим, теоретически это конечно возможно.
Нет, там проблема решается гораздо проще.
>> Вообще-то мы говорили Linq2Objects, там вообще никаким SQL не пахнет. Вы же сказали про императивные циклы, вот я привел пример того, как языке вместо них пишут запросы. Вы, это, сжудения не подменяйте.
Поясняю — LINQ, это расширение декларативных запросов из области реляционных баз на область любых множеств, поэтому SQL — основа того, что получилось в LINQ. Ну а императивные циклы есть способ обработки всё тех же множеств, поэтому если речь идёт о БД, там эту часто повторяющуюся потребность выделили и создали на этой основе язык SQL, после чего (лет 50 спустя) некто наконец решился создать аналог с чуть более широкой областью применения (LINQ). Поэтому я вам и ответил про SQL.
>> Вот я придумал сделать сортировку, которая не зависит от типа объектов (только чтобы он сравниваться умел), а язык, собака, мне не дает его написать
Императивные языки давно и качественно решают эту проблему, и вы это должны отлично знать на примере C#. Ну а в го я не спец, поэтому по нему я вам не подскажу.
>> Это про хаскель из каждого утюга вещают и запросы в гугл подменяют?
А про го разве вещают? Нет, там всё проще — вешают объявление, з/п программиста на го — 200к$, и всё, далее остаётся лишь говорить о чьей-то неконкурентоспособности.
>> Так ваш компромисс это исключительно «хуяк хуяк и впродакшн». Такой себе компромисс, должен сказать.
Я не спорю, любую мысль можно извратить, но компромисс — это не крайность, а потому вы меня просто неправильно поняли, либо понять не захотели.
>> Ненастоящий шотландец
Опять нет. Я вам снова повторю — если кто-то сделал что-то в 5 раз быстрее, значит тот, кто делал до него — клинический дебил, либо ему было плевать на результат (а значит на результат было плевать и всем его начальникам по цепочке до самого верха).
>> вещи вроде паттерн матчинга, лямбд, query-language в языках и асинк-авейт это Early majority, а то что я тут рассказываю — Early adopters. А у человека с опытом всегда преимущество
Точно. У человека с опытом есть большое преимущество — он может расслабиться и лениво поглядывать на безумства Early adopters, ибо когда они наконец нарезвятся вдоволь, можно будет спокойно спуститься с небес и…
отыметь всё стадополучить все ништяки.Но проблема в том, что пока винигрет в сообществе функционалов не устаканился, а это означает, что данная технология ещё молода и не даёт должного эффекта в реальной жизни. Поэтому заниматься активно этой пляской с бубнами — тратить время на развитие недоразвитого организма. Только вот конкретно мне пока не хочется тратить много времени на этого детёныша, просто потому, что для меня есть более интересные темы, а в данной — да, похоже есть кое какие перспективы, но пока они где-то за облаками.
Это важно для мелкого бизнеса, поэтому вас там и удивили детской считалкой. А крупный, и даже средний — им всем плевать на лояльность. Потому что никуда вы от них не денетесь. Ведь если предпочли магазин у дома супермаркету, то как вас не задабривай в службе поддержки (куда вы за всю жизнь один раз — и то вряд ли позвоните), вы всё равно пойдёте в магазин у дома.
В целом же, чисто статистически, требование к службе поддержки одно — она должна быть примерно как у конкурентов. И всё. Если лучше — это почти ничего не изменит. И даже если хуже — тоже не сказать, что бы страшно просядет бизнес. Поэтому её поддерживают в примерно близком к среднему по больнице состоянии, ну и более на неё не отвлекаются.
Вот вы в своём коде использовали значок $, а почему? Знаете?
>> Знать все библиотечные функции не обязательно, достаточно уметь сформулировать вопрос в гугл. А то и в хугл.
Ну так вы слона не продадите. Я тоже могу сказать, что знаю любой язык, но со словарём, ведь делов-то — вбил в гугл-транслейт текст и почти всё понял!
Эффективно использовать инструмент, постоянно ползая по интернету — невозможно.
>> чтобы знать что что-то работает нужно иметь возможность судить об этом по интерфейсу, а не по реализации
Во первых, интерфейсы есть почти во всех императивных языках. Чем в этом плане лучше хаскель? Во вторых, реализация хоть сколько-нибудь сложного алгоритма всегда предполагает знание её пользователем набора ограничений, вне которых алгоритм не работает (или работает криво). Если вы ещё не изучили, что такое возведение в квадрат — какой смысл говорить о функции, которая возводит в квадрат? Даже если весь этот текст содержится в её названии.
>> >> А вот хугл это очень крутая штука, я тут потыкал недавно
>> Достаточно просто сделать поиск по сигнатуре (a -> Bool) -> [a] -> [a]
>> С императивными функциями () -> () так не выйдет, увы.
Почему не выйдет с императивом? Например: (int[]) -> (int[]). Но интересно, а если функция просто переставляет пару значений в массиве, то как вы её отличите от сортировки?
>> Если человек потратил время чтобы изучить его возможности он напишет так же быстро, как и на го
Но он так же потратит меньше времени на изучение го, значит суммарные затраты времени меньше.
>> Я уже не раз говорил, что я предпочту потратить день на изучение фичи, которая будет мне экономить одну минуту каждый день до конца жизни.
Это хорошая максима, но исключительно для тех, у кого времени — вагон. В реальной жизни (если время всё-таки ограничено), приходится находить компромисс. И вот сообщество функциональных программистов здесь склоняется к максимизации времени на долговременно полезные затраты, а в реальной жизни с такой ориентацией быстро становишься неконкурентоспособен.
Я же говорил — будь у меня куча лишнего времени, я бы обязательно много чего поизучал бы. Но даже когда вдруг время появляется, то оказывается, то «много чего» за раз не получается, приходится расставлять приоритеты, а потом находить способ не затягивать с первым выбранным предметом, ибо всё на свете можно копать до бесконечности, но тогда ведь на остальные темы времени никогда не будет. Поэтому компромисс обязателен. Как минимум для тех, кто хочет получить от жизни больше. Но да, можно отказаться от всего остального и заняться самосовершенствованием в хаскеле. Только мне это не кажется полезным.
>> на протяжении всего этого года нам могли бы объяснить принцип, и мы бы для любых фигур могли бы считать, а не только для «одобренных минобром»
Ну здесь же вы опять в сторону индусов уходите, хотя их образ действий критикуете. То есть объяснить принцип вам могли бы, но это был бы лишь некий магический и непонятно как работающий способ. А что бы его понять — нужно пройти курс высшей математики и изучить пределы, производные, интегрирование, плюс ещё что-то там (не помню, давно учил). И если вы предпочитаете получить работающий способ здесь и сейчас, то вы идёте строго по пути индусов. Ну и при этом не будете понимать, как вам расширить круг приложений для своего инструмента, потому что просто не понимаете, как он работает (ведь не изучали высшую математику).
>> Поймите, что вся суть в том, чтобы компилятор ловил ошибки.
Поймите, что уровень, когда вся сложность ограничивается тем, что может компилятор, совершенно недостаточен для вменяемой разработки ПО. Такой подход люди тупо заменяют генерацией кода.
>> Ниже объяснялось, почему не получится это сделать в го. Ни без генериков, ни с ними.
То есть вы поверили, что некий алгоритм в принципе не реализуем на языке, реализующем машину Тьюринга, но при этом отлично реализуем на другом языке, который тоже реализует машину Тьюринга?
>> Спросите у сишарпистов, что понятнее, императивный код на циклах или декларативный на LINQ.
Вы путаете ниши. Есть, например, SQL (более распространённый аналог LINQ). И никто в здравом уме не пишет в императивных языках всё то, что можно сделать на SQL. Поэтому ваш пример абсолютно некорректен.
>> Если для го приличный код можно выдавать через месяц, то на хаскелле через 2-3. На примере того же Rust я слышал именно такую статистику. Вопрос в том, что у вас нет ограничения на потолок.
Ограничивает не язык, а умение придумать правильный алгоритм. Ну а инструмент — он и в африке инструмент. То есть он должен быть удобным, это да, но превозносить удобства до небес, даже заявляя, что «с этим инструментом можно сделать то, чего ни один другой (императивный) инструмент не может» — это неправильно.
>> Я не буду выбирать плохой инструмент только потому, что он модный
Хаскель как раз — модный. То есть продуктивность в реальной жизни он не обеспечивает, но создаёт иллюзию «последнего писка технологичности».
>> Времени вообще никогда не хватает
Картинка весёлая :)
Но про компромисс и при её создании забыли.
>> Мы недавно переписали сервис с джавы на хаскель, и выиграли в 5 раз по памяти и в 10 по производительности
Значит писали сервис индусы. Если переписать сервис с хаскеля на Java, но не по индуйски, то вы ещё больше сэкономите.
>> Что касается экосистемы, то всегда есть Scala
Да, есть. Но всё же пока востребован императив, поэтому я на «тёмной стороне» силы. Вот победит функциональщина, докажет продуктивность в массовой разработке — я к вам обязательно присоединюсь :)
А пока — пусть фанаты функций готовят дорогу для будущего счастья, может даже когда-то у них получится. Я же поигрался и не увидел серебряных пуль и прочего вундерваффе.
Опять не совсем правильный подход. Эволюция ведь, как ни странно, всё ещё работает, то есть отбирает наиболее адаптированных к условиям обитания. Поэтому возникает интересный вопрос — а почему в нынешних условиях процветают индусы? А функциональные языки задвинуты куда-то в академии.
>> Вы читаете текст, который комментируете? Советую почитать про tagless final encoding чтобы узнать о том, как много информации может предоставлять сигнатура функции.
Я читаю текст, который комментирую. А вы читаете? В моём сообщении было про неверно интерпретируемое название. И заметьте — это ещё цветочки. То есть что для полноты понимания вам стоит отказаться от всей документации и попробовать понимать чужой код по сигнатурам.
>> map-reduce (hadoop, spark), erlang, aws lambda… как жаль что «сторонники функционального подхода» продолжают тащить в продакшен эту свою функциональщину
Для справки — aws lambda работает с разными языками, поэтому выделение из них исключительно функциональных говорит о вашей исключительной предвзятости.
Вам кажется, что вы не обычная серая масса? Ну ладно, я не буду вас разочаровывать. Но бизнес всё решает без учёта и моего и вашего мнения. Поэтому, как мне кажется, это просто объективная реальность, данная нам в ощущениях — мы не можем купить хороший сервис. А раз не можем, то на что жаловаться? И да, кто виноват, что мы не можем купить хороший сервис? Это тоже довольно важный вопрос. Потому что качественный ответ на него может изменить всё общество. А без изменения — мы так и останемся неважной для бизнеса серой массой.
Во первых, это подтверждает очевидную истину — не зная в деталях объект приложения усилий, можно нагородить ерунду. Поэтому здесь ничего удивительного нет, кроме одного момента — почему вы удивляетесь, что не можете понять смысл целого, когда не знаете деталей?
Во вторых, разбираясь с хаскелем, в голове не заучившего наизусть все приоритеты и все библиотечные функции программиста, происходит тот же самый комбинаторный взрыв. Но структура хаскель-программ каким-то образом способствует вселению уверенности в происходящем в голову, вот например вас, не разбирающегося в приоритетах и сути происходящего в программе. При этом, как было замечено ранее, незнание деталей может привести к проблемам. А уверенность в происходящем, без знания деталей, как раз очень способствует наступанию на разные грабли.
Вообще, когда я не понимаю, что происходит при выполнении программы, меня это напрягает. Я оказываюсь в ситуации, когда должен полагаться на волю случая — а вдруг там внутри всё само как-то правильно сложится? И да, хаскель содержит встроенные средства контроля разных косяков с типами, а так же сама структура вызовов кое-что подправляет за программиста, но ведь это всё — абсолютно неявно, неочевидно и непонятно, ровно до тех пор, пока вы не вызубрите все приоритеты и все используемые функции. А что бы вызубрить все функции стандартных библиотек, надо потратить немало времени. Без зазубривания же вы не сможет понять чужой код. Точнее — по вашему, как вы выше сообразили без понимания происходящего внутри, представить себе нечто вполне возможно, и даже хаскель поможет вам своими приятными качествами, но тем не менее — вы по прежнему не понимаете, что происходит внутри, а значит по прежнему не понимаете, где находится проблема, если после запуска программа выдаст не то, что вы ожидали. И как только такая неожиданность случится — всё, полностью и дословно повторится история с го, когда по частям вам кажется, что всё понятно, а в целом — ничего не работает. А всё из-за чего? Из-за отсутствия понимания происходящего внутри. А для получения такого понимания вам нужно потратить много времени на зазубривание приоритетов и хотя бы функций из стандартной библиотеки (а их там несколько десятков, плюс десяток занимательных типов, и это без монад и прочего IO). Вот в этом и проблема хаскеля — он не предназначен для тех, кому нужен простой и быстрый результат. А это как раз все те индусы. И как бы вы не возражали, но «индусов» на земле на порядки больше, чем тех, кто готов потратить время на спокойное изучение хаскеля, на зазубривание приоритетов и изучения всех библиотечных типов и функций. Это аналогично высшему образованию — нужно пройти высшую математику, и лишь потом станет понятно, почему теория автоматического управления целевым объектом действительно даёт правильный результат. Но вспомним — сколько людей так и остаются без высшего образования? Вот такой же процент не будет готов и к изучению хаскеля. А вот го они осилят легко. Потому что там сразу ясно, что происходит. Ну а комбинаторная сложность комплексных явлений, будь то текст программы или что угодно ещё, всегда высокая. И в хаскеле с ней бороться невозможно без понимания всех функций, типов, приоритетов. Хотя да, можно полагаться на удачу — запустил и оно как-то само всё сделало. Но это не наш метод. Это скорее опять к индусам, которые понадёргают из примерчиков составляющих и получают нечто, вроде даже работающее, но все проблемы, кроме самых очевидных, индусы никогда не вылавливают, и не важно, на хаскеле они это делают или на го. Но го они хотя бы способны понять. А вот хаскель — практически никогда не поймут до уровня, который позволит им разобраться в сложных проблемах.
>> Мне кажется, что такой библиотеки просто в принципе нет, по крайней мере я не представляю, как её создать с теми возможностями, что дает Go.
Если вы в курсе, что такое дженерики, то всё вы легко поймёте. На крайний случай — есть просто тип Object, плюс интроспекция — вот вам и рецепт для повторения. То есть при минимальном желании библиотеку написать вполне возможно. Ну а возражения других участников о якобы невозможности такого чуда — оставим на их совести.
И о совести. Почему-то сторонники хаскеля всегда наиболее воинственно отстаивают преимущества своего любимого чуда. И при этом игнорируют любые указания на недостатки. Вот почему бы это?
>> язык, где по сигнатуре можно понять всё, что происходит внутри (например, есть вывод на экран/запись в БД/… или нет) очень экономит это самое время
Нельзя ничего понять по сигнатуре, если не знаешь алгоритма внутри вызываемой функции. Можно строить предположения, можно догадываться, можно гадать на кофейной гуще, но полноценно понять — нельзя. Назовём функцию вычисления квадрата cube, вы по её сигнатуре поймёте, что с ней что-то не так?
>> мне кажется, что 15 строк прочитать проще, чем 60
Опять — вам кажется. В одну строку можно вытянуть выражения почти на любом языке, но понятней от этого не становится. Та же обработка в циклах на императивных языках часто гораздо нагляднее, нежели то же самое, но с рекурсивными вызовами, без которых в принципе нельзя сделать что-то вменяемое на функциональных языках. И да, в императиве при этом строк будет больше. Но понятность-то будет лучше!
>> Для человека с хотя бы годом опыта работы в любом несистемном языке не будет никаких проблем с изучением хаскелля
Вопрос не в возможности изучения, а в скорости. Индус будет изучать лет 5 (может утрирую, но не сильно). А го изучит параллельно с работой, даже не заметит. Есть разница?
>> Ну а быть или не быть «обычным индусом» каждый человек пусть решает сам. Мне кажется, что разработчики достойны лучшего и должны ценить своё время
Проблема не в самооценке, а в объективно существующей потребности. Потребность простая — надо много и быстро. А индусы на хаскеле — не способны ни много, ни быстро. И как бы вы не решали, кем хотите быть, проблема от этого никуда не денется.
И да, разработчики, которые ценят своё время, как раз очень озабочены затратами этого самого времени на зазубривание хаскеля хотя бы на уровне стандартного синтаксиса и Prelude. То есть если времени девать некуда — ну тогда ОК, можно заниматься хаскелем. А если есть актуальные задачи?
Вообще, пришла в голову простая мысль — сторонники функционального подхода реально не знают, что такое требования жизни. То есть в академиях и прочих неспешно грызущих гранит науки заведениях действительно можно годами ваять на хаскеле примитивный софт, потом его вылизывать, совершенствовать и т.д. И в конце получить нечто, от чего можно выпячивать губу, мол вон что мы сотворили! Но как коснёшься реального применения (то есть в реальной жизни), то сразу вылазят косяки хоть и достаточно общего подхода, но далеко не универсального. Возьмите стандартный (или просто распространённый, я тут не возьмусь вешать ярлыки) ORM на хаскеле — концепт изначально ориентирован на манипуляцию SQL, а в реальной жизни акцент смещается на манипуляцию с результатами работы SQL. И это сильно не одно и то же. Хотя да, подход в хаскельном варианте солидный, обобщённый и т.д. Но пользоваться — неудобно. Может для мелких академических задач это нормально, но для реальной жизни — ну не то, просто неудобно.
В целом я бы повозился с тем же хаскелем побольше, но вот реально — а что толку? Куда я его прикручу с его неудобными ORM-ами и прочим? Народ давно попробовал и сделал вывод — для enterprise разработки оно реально неудобно. Куча гемороя с поддержкой состояния, малое количество библиотек и неудобство существующих (хотя хаскелисты здесь будут долго кидаться гнилыми помидорами).
Я же специально выделил часть вашего текста:
>> Так я только рад буду, если вы покажете какую-нибудь библиотеку на го, которая позволит сделать все то же самое.
Так суть-то не в показе библиотеки, а в сравнении двух языков на основании нахождения для одного из них уменьшающего сложность решения. Простая случайность (нагуглилось нужное) приводит к выводу о порочности всего языка. Вот про это я и говорил.
>> Моя грубая оценка: опытный го-разработчик написал бы минут за 5, а опытный хаскеллист минуты за три.
Пусть даже так (хотя не факт), но что это меняет? В любой серьёзной разработке собственно написание кода — это малая часть работы. И разница 3-5 минут вообще ничего не решает. А решает, например, лёгкость освоения языка, ибо нужно много программистов, а где их взять? И вот в случае хаскеля простота обучения, скажем прямо, так себе. А в случае го — всё доступно. Именно поэтому гуглы и придумали го, ибо им нужны миллионы индусов, которые задёшево и быстро освоят новый язык. Представьте себе, сколько времени займёт освоение хаскеля обычным индусом (из тех самых миллионов). Представили? Вот поэтому го идёт в массы, а хаскель тихо курит бамбук в академической среде.
ЗЫ. Это всё не спора ради. Просто замечания по смыслу текста. Надеюсь на некоторое дополнение к статье с осмыслением данных замечаний. Хотя с другой стороны — количество просмотров упадёт буквально через пару дней, так что может и не стоит заморачиваться с дописанием.
Да, в этой сфере нас ждут потрясающие перспективы (в самом прямом смысле) — всю душу вытрясут.
Вообще, полноценный ИИ действительно очень близок. И естественно, если он будет в руках нынешних хозяев мира, то… Видимо, нам всем в таком мире будет отведено место лишь около известного по отдельным кинофильмам оборудования.
Она дедлочится потому, что автор данного текста на самом деле не понимает того, что происходит в программе, хотя и заявляет, что понимает каждую строчку. Я надеюсь, что автор честно сам себе в этом признается.
Следующий момент — автор скачал хаскелевскую библиотеку, которая берёт на себя все проблемы с распараллеливанием, затем вставил её в свой код на хаскеле, потом не нашёл аналога на го и начал изобретать велосипед «своими руками», после чего изобретение «не поехало». И какой из этого делается вывод? Ну конечно же — го отстой, а хаскель — это круто.
Не наличие библиотеки против непонимания работы го, а именно го виноват во всём.
Автор, может вы передумаете?
И наконец, на С# код написан много быстрее, чем на хаскеле. Из минусов — некоторая кажущаяся объёмность переделки кода под новую структуру. Но разве мы постоянно меняем структуры в программе? Вроде нет. Тогда каков вес этого минуса? И каков вес плюса, позволившего очень быстро написать решение на привычном языке?
В целом мне тоже го не нравится, но всё же в данном тексте вижу необъективность, а потому показываю пальцем. Сорри, автор, минусуй, может и не проиграешь.
Гугл разработал сервис распространения приложений, значит он «отвечает за соответствие требованиям. И если заказчик хочет чего-то нарушающего, разработчик об этом должен знать и предупредить». И да, гугл предупреждает, но примерно так — приложение заблокировано, дальше думай сам.
Как вы думаете, гугл должен выполнять ваши правила? А если нет, то почему другой разработчик должен?
Малый бизнес = ужасно неэффективная потеря времени. Если вы слыхали про эффект масштаба, то наверняка поймёте, что с малым бизнесом не так. Единственный его плюс — гибкость. Но гибкость эта проявляется лишь на фоне стандартного подхода к управлению в больших конторах. Когда же контора целенаправленно создаёт гибкую систему, то никакой малый бизнес рядом уже стоять не может. Сравните разного рода конструкторы для квалифицированных пользователей с возможностями малого бизнеса в таких сферах. Например какие-нибудь математические или статистические программы, с которыми работают конечные пользователи. Вот где здесь место малому бизнесу? Зачем там кто-то лишний?
Правда пока что есть конструкторы для неквалифицированных пользователей (типа 1С), но по сути это тот же вариант, что и показанный выше, поскольку эти конструкторы ориентированы на профессионально занимающихся их использование. То есть все эти настройщики 1С — это как раз и есть те самые потребители, под которых заточены конструкторы. Ну а бухгалтера просто примут всё то, что им согласится купить начальство. В итоге настройщики 1С работают точно так же, как и обычные наёмные работники, но тешат себя надеждой на некий «успех», которого обычно не бывает. Но эффективность такой работы низкая. Прямое сопровождение от производителя было бы эффективнее, но с этой стороны уже стоит неумение построить гибкую систему такого сопровождения. Точнее она построена, но в максимально людоедском варианте, только такой вариант всегда приводит к заявлениям типа «Проблема актуальна только для России/СНГ», хотя на самом деле проблема актуальна для всех, кто решил строить людоедскую систему, но такую причину обычно люди видеть не хотят (даже не знаю, с чего у них такая святая вера в идеальность закона джунглей).
Ну и конечно, некие мелкие задачи по сопровождению мелкого же бизнеса — ну кому это интересно? Да, тем, кто работает за обычную з/п. Но с точки зрения добавленной стоимости — что это за деньги? Это почти невидимые в масштабах экономики суммы. То есть основную добавленную стоимость создают коллективы. А одиночек вот так используют лишь ради возможности игнорировать ТК. Но что это значит для фрилансера? Это значит, что он реально дешевле наёмного работника.