Здравствуйте, a_g_99, Вы писали:
__>python vs haskell. почему python имеет гораздо большую популярность чем хаскелл, хотя оба языка появились примерно в одно и то же время?
python проще на порядок, его вообще учить не надо, если еще хоть какой-то язык знаешь.
С другой стороны, язык поощряет написание овнокода (как и какой-нть JS или там бейсик), и действительно, овнокода на нем навалом, и все проблемы динамики в полный рост (я помню, был какой-то большой и известный пакет, в котором были внутри синтаксические ошибки. Просто они были под ифом, который у обычных юзеров не срабатывал — а у нас сработал и доставил неимоверно)
языки со статической проверкой типов вообще менее популярны, чем динамические, ибо 95% (с) программистов не хотят удовлетворять компилятор, а хотят *як *як и в продакшен и айда пиво пить, а если че не так — нехай скрэшится.
Здравствуйте, jazzer, Вы писали:
J>python проще на порядок, его вообще учить не надо, если еще хоть какой-то язык знаешь.
Это большое преимущество, вы согласны?
То бишь главное преимущество которое я слышу от хаскелистов на самом деле это "говнокодить на пайтоне каждый сможет, а вот хаскел освоить тяжело. я редкий специалист и буду востребован". Это конечно полное заблуждение.
J>С другой стороны, язык поощряет написание овнокода (как и какой-нть JS или там бейсик), и действительно, овнокода на нем навалом, и все проблемы динамики в полный рост (я помню, был какой-то большой и известный пакет, в котором были внутри синтаксические ошибки. Просто они были под ифом, который у обычных юзеров не срабатывал — а у нас сработал и доставил неимоверно)
Так и здесь хаскелл не нужен. Возьмите скажем любимицу-старушку банков java. Статическая типизация + простота использования. Что там говнокода меньше стало?
Вопрос говнокода — это прежде всего вопрос культуры разработки. Он решается с помощью статического анализа (типа коверити), рефакторинга и правильным построением команды и проекта.
Что есть главный враг говнокода? Это первичная ясность, простота кода, эффективная абстракция от сложной концепции к простым паттернам. Хаскелл не может сделать этого из коробки. Он "витает" в высоком мире трансьюдеров, каррирования и пр. Как результат количество "непонятного"=="говнокода" кода будет существенно выше чем в пайтоне. Другая огромная проблема — мэйнтейнить все это.
Здравствуйте, jazzer, Вы писали:
J>языки со статической проверкой типов вообще менее популярны, чем динамические, ибо 95% (с) программистов не хотят удовлетворять компилятор, а хотят *як *як и в продакшен и айда пиво пить, а если че не так — нехай скрэшится.
Я как — то на haskell решил что-то запилить используя yesod. Так вот некоторые пакеты там выдавали ошибку при сборке, тоже были синтактические ошибки внутри. Те народ вообще даже не запускал то, что напихали в cabal.
Здравствуйте, a_g_99, Вы писали:
__>Здравствуйте, jazzer, Вы писали:
J>>python проще на порядок, его вообще учить не надо, если еще хоть какой-то язык знаешь.
__>Это большое преимущество, вы согласны?
Смотря для чего. Чтоб за один день въехать и накропать что-то как-то работающее — безусловно. Чтоб писать хороший код, надо становиться профессионалом, что гораздо дольше, и в этом смысле двухнедельный выигрыш при въезжании в язык с нуля роли не играет, имхо. Гораздо важнее изучить и прочувствовать идиомы, перестроить образ мыслей — это все занимает время (у некоторых бесконечное — они так и продолжают писать в высокоуровневых языках как на бейсике).
__>То бишь главное преимущество которое я слышу от хаскелистов на самом деле это "говнокодить на пайтоне каждый сможет, а вот хаскел освоить тяжело. я редкий специалист и буду востребован". Это конечно полное заблуждение.
Я такого не видел, хотя верю, что такое встречается (такое везде встречается).
Обычно говорят (из того, что я видел, и помимо стандартных аргументов в пользу статической типизации), что Хаскель (и ФП вообще) как раз облегчает управление сложностью и сложность кода в результате потока изменяющихся требований растет с меньшей скоростью.
J>>С другой стороны, язык поощряет написание овнокода (как и какой-нть JS или там бейсик), и действительно, овнокода на нем навалом, и все проблемы динамики в полный рост (я помню, был какой-то большой и известный пакет, в котором были внутри синтаксические ошибки. Просто они были под ифом, который у обычных юзеров не срабатывал — а у нас сработал и доставил неимоверно) __>Так и здесь хаскелл не нужен. Возьмите скажем любимицу-старушку банков java. Статическая типизация + простота использования. Что там говнокода меньше стало?
Нет. Наоборот, они именно жабу и упоминают в презентации, это я тут дипломатично на кобол стрелки перевел
__>Вопрос говнокода — это прежде всего вопрос культуры разработки. Он решается с помощью статического анализа (типа коверити), рефакторинга и правильным построением команды и проекта.
Ну вот утверждается, что в ФП все это проще и в каком-то виде из коробки.
__>Что есть главный враг говнокода? Это первичная ясность, простота кода, эффективная абстракция от сложной концепции к простым паттернам. Хаскелл не может сделать этого из коробки.
Вот утверждают, что все ровно наооброт. Что ФП-код гораздо более ясный и прозрачный и гораздо лучше работает в стиле "собрать из крипичиков, и чтоб не макароны получились".
__>Он "витает" в высоком мире трансьюдеров, каррирования и пр. Как результат количество "непонятного"=="говнокода" кода будет существенно выше чем в пайтоне.
Это статьи витают, а не продакшен-код. Вон статьи по Немерле тоже витают бг знает где, хотя народ при этом, вроде как, пишет нормальный читабельный рабочий код безо всяких этих завихрений. А все завихрения живут (и должны жить, иначе по рукам, по рукам) в библиотеках.
__>Другая огромная проблема — мэйнтейнить все это.
В смысле набора программеров? Ну да, хаскеллистов меньше, чем джавистов, тут спору нет.
Здравствуйте, Alex912, Вы писали:
A>Здравствуйте, jazzer, Вы писали:
J>>языки со статической проверкой типов вообще менее популярны, чем динамические, ибо 95% (с) программистов не хотят удовлетворять компилятор, а хотят *як *як и в продакшен и айда пиво пить, а если че не так — нехай скрэшится.
A>Я как — то на haskell решил что-то запилить используя yesod. Так вот некоторые пакеты там выдавали ошибку при сборке, тоже были синтактические ошибки внутри. Те народ вообще даже не запускал то, что напихали в cabal.
Ну так не собралось же, а не в продакшене навернулось, как в нашем случае. Хотя, конечно, позор.
J>языки со статической проверкой типов вообще менее популярны, чем динамические, ибо 95% (с) программистов не хотят удовлетворять компилятор, а хотят *як *як и в продакшен и айда пиво пить, а если че не так — нехай скрэшится.
Ну и потому что проблемы типов обычно — мизерная часть собственно проблем в коде. У нас в команде вот за год появился первый тикет, который напрямую связан с ошибкой типов. Все остальные проблемы — это логика.
Ну и да. Let it crash рулит Его, правда, никто готовить не умеет (мы тоже )
Здравствуйте, a_g_99, Вы писали:
__>python vs haskell. почему python имеет гораздо большую популярность чем хаскелл, хотя оба языка появились примерно в одно и то же время?
Дык Саймон Пейтон Джонс сказал же "avoid success at all costs".
Они не ставили своей целью популярность, скорее наоборот.
Здравствуйте, jazzer, Вы писали:
J>Проблема с рефакторингом решается, как выяснилось, очень просто — через специальный режим компилятора, когда проверяется только то, что реально используется, а не всё на свете
Вот только странно, что авторы доклада этого не знают (или делают вид, что не знают). Хотя у них свой компилятор (и не совсем Хаскелла), и возможно, он этого не умеет.
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, jazzer, Вы писали:
J>>Проблема с рефакторингом решается, как выяснилось, очень просто — через специальный режим компилятора, когда проверяется только то, что реально используется, а не всё на свете
N>Вот только странно, что авторы доклада этого не знают (или делают вид, что не знают). Хотя у них свой компилятор (и не совсем Хаскелла), и возможно, он этого не умеет.
Так это разные люди же — те, которые жаловались, и те, которых презентация. Видимо, у тех, которых презентация, никаких проблем с рефакторингом нет, они все знают и считают очевидным
a_g_99,
__>Что есть главный враг говнокода? Это первичная ясность, простота кода, эффективная абстракция от сложной концепции к простым паттернам. Хаскелл не может сделать этого из коробки. Он "витает" в высоком мире трансьюдеров, каррирования и пр. Как результат количество "непонятного"=="говнокода" кода будет существенно выше чем в пайтоне. Другая огромная проблема — мэйнтейнить все это.
Главный враг говнокода — профессионализм. Остальные выводы — ложные, потому что следуют из ложной посылки.
Здравствуйте, Mamut, Вы писали:
M>Ну и потому что проблемы типов обычно — мизерная часть собственно проблем в коде. У нас в команде вот за год появился первый тикет, который напрямую связан с ошибкой типов. Все остальные проблемы — это логика.
Ну вот сторонники продвинутых (или хотя бы приличных) систем типов как раз и ратуют за смещение этой границы, чтобы как можно больше логики кодировать в типах и проверять компилятором. Средний питонист/джаваскриптер/эрлангист может и не догадывается, что его "проблема в логике" может в другом языке быть проблемой с типами и быть поймана компилятором. Чем меньше твой язык позволяет выразить типами, тем меньше у тебя ошибок с типами и тем больше ошибок "в логике", это естественно.
M>>Ну и потому что проблемы типов обычно — мизерная часть собственно проблем в коде. У нас в команде вот за год появился первый тикет, который напрямую связан с ошибкой типов. Все остальные проблемы — это логика.
DM>Ну вот сторонники продвинутых (или хотя бы приличных) систем типов как раз и ратуют за смещение этой границы, чтобы как можно больше логики кодировать в типах и проверять компилятором.
А потом дебажить типы, когда логика закодирована неправильно
DM>Средний питонист/джаваскриптер/эрлангист может и не догадывается, что его "проблема в логике" может в другом языке быть проблемой с типами и быть поймана компилятором. Чем меньше твой язык позволяет выразить типами, тем меньше у тебя ошибок с типами и тем больше ошибок "в логике", это естественно.
Действительно, ведь раз логика закодирована типами, она перестает быть логикой, ага, и никогда не может быть неверной.
Здравствуйте, jazzer, Вы писали:
К>>Мы совсем-совсем не гики-энтузиасты, но компилятор под себя запилим
J>Э-э-э, а какая связь? Айтишники в любой фирме должны быть гиками, иначе нафиг они нужны. Во многих конторах хачат GCC и собирают собственные его билды — и что теперь, С/С++ — для гиков на основании этого?
J>Мои слова про гиков относились к заказчикам (например, профессор в универе, для которого студент пишет эзотерическое исследование, или посетители конференций по теории типов). Банк в качестве заказчика — очевидно не гик.
Пусть не гики. Тем не менее то, что ребята модифицируют под себя компилятор, это отличная антиреклама Haskell'а:
— Неужели, существующие тулы настолько нехороши, что для использования в банковской сфере их нужно улучшать под себя?
— Раз их нужно иногда менять, готова ли наша компания этим заниматься?
P.S. в период увлечения Emacs'ом я понял, что меня "прёт" от допиливания его под себя. Работа при этом страдает.
Здравствуйте, Mamut, Вы писали:
M>А потом дебажить типы, когда логика закодирована неправильно
Для типов есть легковесная верификация, в случае их отсутствия не все так радужно.
M>Действительно, ведь раз логика закодирована типами, она перестает быть логикой, ага, и никогда не может быть неверной.
Она не перестает быть логикой, она представляется в форме, которая хорошо подходит для автоматической проверки.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Константин, Вы писали:
К>Пусть не гики. Тем не менее то, что ребята модифицируют под себя компилятор, это отличная антиреклама Haskell'а:
А кто сказал, что немодифицированная версия не будет работать? Просто они дозаточили под свои нужды.
К>- Неужели, существующие тулы настолько нехороши, что для использования в банковской сфере их нужно улучшать под себя?
Ну вот, например, компиляция в байткод. Язык не изменился ведь, зато стало можно запускать на любой платформе.
Тот же С++ тоже вполне можно было бы компилять в байткод, если бы компиляторостроители озаботились этим (во всех главных компиляторах есть промежуточное представление, которое почти не зависит от языка и потом просто скармливается бэк-энду). Можно было бы захачить тот же GCC, чтоб он сохранял промежуточный образ в файл, и потом этот файл распространять, чтоб он докомпилировался уже у заказчика на месте.
Причем, насколько я знаю, некоторые конторы GCC таки хачат (не в направлении байткода, а больше на тему кодогенерации, расширений, дополнительных метаданных и т.п.) Тем более что GCC сейчас вообще плагины уже поддерживает, так что заточка еще проще стала. И что, это антиреклама С/С++/что-там-еще-GCC-умеет-собирать?
К>- Раз их нужно иногда менять, готова ли наша компания этим заниматься?
Ну вот компиляторы же все апгрейдят плюсовый/шарповые, и ничего, вроде. Или тоже не готовы? Так на джава-1/С++98/... и сидите? Или новая версия языка или новое расширение компилятора — это антиреклама языку в целом?
К>P.S. в период увлечения Emacs'ом я понял, что меня "прёт" от допиливания его под себя. Работа при этом страдает.
Это ортогонально. Они в компиляторе допилили совершенно конкретные и очень практичные вещи. Типа сериализации функций — круто же: упаковал, послал по сети, на том конце (на другой платформе, может даже) принял, распаковал, запустил, все работает.
Это не просто улучшательства ради улучшательства.
Здравствуйте, Константин, Вы писали:
К>Пусть не гики. Тем не менее то, что ребята модифицируют под себя компилятор, это отличная антиреклама Haskell'а:
Они не модифицировали какой-то существующий компилятор. Они написали компилятор хаскелеподобного языка Mu (при условии, что энергичный язык можно считать хаскелеподобным).
Ну и они используют и обычный GHC, Mu у них что-то вроде скрипта для написания бизнес-логики, у него какая-то интеграция с Java/.Net/Excel, но сложно что-то сказать точно — никто за пределами их конторы Mu не видел.
К>- Неужели, существующие тулы настолько нехороши, что для использования в банковской сфере их нужно улучшать под себя?
Существующие в 2008-м году? Серьезно? В этом году для хаскеля даже строк нормальных не было, а массивы нормальные только появились в экспериментальном виде. 2008 год — это GHC 6.8, первый рантайм в котором более-менее SMP работал спустя две версии появился. Да что SMP — тогда с юникодом-то нельзя было стандартными средствами работать.
Вообще, это некоторое упрощение, но можно считать, что то, что сейчас понимается под словом "хаскель" появилось примерно в 2011 году. Хаскель до 2011-го это как C++ времен 80-х годов.
В общем, то, что они что-то там свое начали лепить в 2008 совсем не удивительно. Но, в любом случае, утверждение о том, что они сейчас используют только какой-то свой хаскель с исправленными ошибками не соответствует действительности, или, по крайней мере, не соотвествует тому, что написано в презентации или например тому, что они оплачивали некоторые работы для улучшения у GHC поддержки Windows.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, Константин, Вы писали:
К>>Пусть не гики. Тем не менее то, что ребята модифицируют под себя компилятор, это отличная антиреклама Haskell'а:
K>Они не модифицировали какой-то существующий компилятор. Они написали компилятор хаскелеподобного языка Mu (при условии, что энергичный язык можно считать хаскелеподобным).
А почему нельзя? Я так понимаю, отсутствие ленивости только убивает разные бесконечные последовательности, да и то с оговорками, не?
Остальное же все остается — правила вывода, паттерн-матчинг, частичное применение и т.п...
Здравствуйте, Mamut, Вы писали:
DM>>Ну вот сторонники продвинутых (или хотя бы приличных) систем типов как раз и ратуют за смещение этой границы, чтобы как можно больше логики кодировать в типах и проверять компилятором.
M>А потом дебажить типы, когда логика закодирована неправильно
Да, а что в этом плохого? Особенно, когда и до дебага-то не доходит, т.к. проблемы уже на стадии компиляции прояаляются.
DM>>Средний питонист/джаваскриптер/эрлангист может и не догадывается, что его "проблема в логике" может в другом языке быть проблемой с типами и быть поймана компилятором. Чем меньше твой язык позволяет выразить типами, тем меньше у тебя ошибок с типами и тем больше ошибок "в логике", это естественно.
M>Действительно, ведь раз логика закодирована типами, она перестает быть логикой, ага, и никогда не может быть неверной.
Зачем клоуна строишь? Ничего подобного я не говорил и не имел в виду.
Его, правда, никто готовить не умеет (мы тоже 
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
