• Total Haskell code base: >2M lines, >150 contributors (~20 core), >110k commits.
• Haskell code everywhere: real time pricing, risk management, data analysis, regulatory systems, desktop and web GUIs, web services, algo pricing, end-user scripting, and as plugins to C++, Java, C#, Excel.
• Windows, Linux, clusters and grids. On servers and desktops in >30 countries.
GUIs: Generate native Windows WPF GUI or JavaScript app from single Haskell impl.
Bindings: Tons of bindings to external services. Haskell as API glue.
In-house Haskell compiler: `Mu’. One of Lennart’s many Haskell compilers.
• Whole world optimizing compiler.
• Compiles to portable bytecode – same blob runs on Linux or Windows.
• Values, closures, functions can be serialized.
J>К вопросу о том, что хаскель не нужен и это инструмент для гиков-энтузиастов и никто его в продакшене в здравом уме использовать не будет
В банках чего только не используют, как ни странно. Но таким презентациям советую не верить ни на грош. Мы тоже такие презентации еще года два тому назад создавали.
Судя по тому, что они написали на нем все, что только можно написать, их база кода — мешанина неуправляемого кода, в котором никто не может разобраться. Поэтому им понадобилось 150 разработчиков (из которых 20 — core). В общем, ровно то, что было/есть у нас в Кларне, только у них Хаскель, а у нас Erlang.
Fast delivery — это тоже в какой-то мере ложь Потому что им нужен delivery просто быстрее, чем в других банках. У нас релизы раз в неделю, все люди из банковской индустрии «как это так? как вы можете так часто релизить, шаманы!»
Самое главное во всей презентации — в самом конце.
And, even if the language has the tools, developers need taste and guidance to use them
Ну, то есть если нет насаждающих это диктаторов, все будет очень, очень плохо (ну, как в Кларне ).
Из того, за что зацепился глаз:
Often working from verbal, ad hoc evolving spec. And at best from informal functional specs.
Spec often refined/derived based on the Haskell implementation.
o “No plan survives contact with implementation”
Ахахахахаха, то есть мяу. На русский это переводится так: «их база кода — мешанина неуправляемого кода, в котором никто не может разобраться». У нас тут тоже периодически спеки реверс-инжинирят из реализации. Именно потому что "ad-hoc", реализацию пишут быстро «надо вчера» и в компании есть один человек, который знает, как это работает, но он уволился полгода тому назад.
Writing lots of apps; services; libraries in Haskell.
Ну, у нас в нашей системе тоже было все на Erlang'е — от генерации PDF'ов, до роутинга звонков в customer support. В итоге никто не знает, что это, где оно находится, и как оно работает. И надо 150 человек (вместо реально 20), чтобы эти авгиевы конюшни вычистить.
Heavy use of process isolation. Baby Erlang in Haskell.
Old code doesn’t fall apart – large, (very) strongly typed code bases don’t rot.
Это ложь. Потому что требования меняются, люди уходят, и как эта хренотень работает в итоге не знает никто. От того, что оно принимает на вход TContact2 а возвращает TAddress1, легче не становится, потому что половина нового кода использует TContactInfo, и как конвертировать одно в другое не знает никто (а как оно выглядит в базе данных — это еще один отдельный песнь).
Use the machine to... Document the design for later developers
идет вразрез с процитированным выше:
Often working from verbal, ad hoc evolving spec. Spec often refined/derived based on the Haskell implementation.
Если все, что есть по спецификациям, это — код, то все, приплыли. Потому что люди увольняются и забывают, а многие вещи (особенно «это наш главный клиент, для него проводим особую интеграцию») сильно рушат самые внятные представления о том, как система должна работать.
Make wrong code impossible to write
Ахахаха. Из того, что у тебя проверены все типы, никак не следует, что твоя реализация real time pricing или risk management хоть близко похожа на правду.
Strong, expressive types give us machine-checkable, modular software
• APIs become self-describing
Нет, не становятся. Особенно, если тебе сделать несколько разных вызовов подряд. Особенно, как я уже указывал выше, ты не имеешь ни малейшего представления, что делать с API, который требует TContact2 на вход, если у тебя на руках TContactInfo.
Ах, да Я уже умолчу, что когда contact:is_empty(contact:new()) возвращает false (а должен true), от этого не спасают ни системы типов, ни «самописывающиеся API».
Any dev can build systems without worrying about implementation internals.
Just fit types together
После чего в пятницу вечером сервер ложится и не поднимается, потому что какой-то новичок написал код, позволяющий создавать отчеты о продажах за целый год, что начало поднимать с диска терабайты данных в память. А что? API-вызов всего лишь требует типа TDate
Остальное вполне норм, хотя и в стиле капитана очевидности
Здравствуйте, Mamut, Вы писали:
M>В банках чего только не используют, как ни странно. Но таким презентациям советую не верить ни на грош. Мы тоже такие презентации еще года два тому назад создавали.
этой — можно верить.
я, когда работал в Сингапуре, был знаком с человеком, который как раз на хаскеле в SCB и писал.
ну и да, хорошим спецам по хаскелю и шарящих в предметной области, там были готовы много платить и таких спецов у них был постоянный дефицит.
M>>В банках чего только не используют, как ни странно. Но таким презентациям советую не верить ни на грош. Мы тоже такие презентации еще года два тому назад создавали.
LS>этой — можно верить. LS>я, когда работал в Сингапуре, был знаком с человеком, который как раз на хаскеле в SCB и писал. LS>ну и да, хорошим спецам по хаскелю и шарящих в предметной области, там были готовы много платить и таких спецов у них был постоянный дефицит.
Ну, два-три года тому назад нашей тоже можно было верить. И эрлангистов мы набирали тоже Там просто в презентации есть моменты, которые я процитировал, которые ну точь-в-точь копия того, что происходит в Кларне
Здравствуйте, jazzer, Вы писали:
J>К вопросу о том, что хаскель не нужен и это инструмент для гиков-энтузиастов и никто его в продакшене в здравом уме использовать не будет
Это был, есть и будет инструмент для гиков, либо компаний которые могут запросто нанять 200 человек вместо 20 на один и тот же продукт и не заметить этого. Правда, в конце концов, вся эта писанина придет в состояние "говно неподдерживаемое" и после нескольких лет мозгового штурма все же найдется человек, который таки решится предложить начать её переписывать на каком-то более адекватном для продашна языке или хотя бы документировать... Но это будет потом, а пока будут победные крики этих 200 человек, которым и платят хорошо и работать увлекательно
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, jazzer, Вы писали:
J>>К вопросу о том, что хаскель не нужен и это инструмент для гиков-энтузиастов и никто его в продакшене в здравом уме использовать не будет
KP>Это был, есть и будет инструмент для гиков, либо компаний которые могут запросто нанять 200 человек вместо 20 на один и тот же продукт и не заметить этого.
Вообще сейчас для банков не самое лучшее время, все пояса затягивают и cost reduction-ом занимаются уже который год. Маловероятно, чтоб в таких условиях кто-то дал согласие на набор 200 человек вместо 20 — это все ж таки десятикратные траты.
KP>Правда, в конце концов, вся эта писанина придет в состояние "говно неподдерживаемое" и после нескольких лет мозгового штурма все же найдется человек, который таки решится предложить начать её переписывать на каком-то более адекватном для продашна языке или хотя бы документировать... Но это будет потом, а пока будут победные крики этих 200 человек, которым и платят хорошо и работать увлекательно
А "в конце концов" — это когда?
Вот сам Don Stewart работает там с 2011 года, Lennart и прочие звезды — с 2008. Или ты о десятках лет говоришь?
Я вот видел проекты, которые превращались в то, что ты сказал, года за два (некоторые — вообще еще до продакшена, и благополучно умирали, не родившись, и слава богу)
Здравствуйте, Mamut, Вы писали:
M>Самое главное во всей презентации — в самом конце.
M>
M>And, even if the language has the tools, developers need taste and guidance to use them
Ну раз это самое главное, то цитируй уж до конца, что ли:
You can write Java in any language
M>Ну, то есть если нет насаждающих это диктаторов, все будет очень, очень плохо (ну, как в Кларне ).
Давай, я сыграю в КО — приведенная цитата верна вообще безотносительно языка.
На коболе/бейсике/подставить-по-вкусу можно писать на любом языке, и именно нужны диктаторы, насаждающие в команде хороший стиль, хорошую архитектуру и прочая.
Иначе да, все будет очень, очень плохо (не знаю, что там в Кларне, но верю на слово)
M>>And, even if the language has the tools, developers need taste and guidance to use them
J>Ну раз это самое главное, то цитируй уж до конца, что ли: J>
J>You can write Java in any language
Ну дык У нас пытались Haskell и OCaml на Эрланге писать
M>>Ну, то есть если нет насаждающих это диктаторов, все будет очень, очень плохо (ну, как в Кларне ).
J>Давай, я сыграю в КО — приведенная цитата верна вообще безотносительно языка. J>На коболе/бейсике/подставить-по-вкусу можно писать на любом языке, и именно нужны диктаторы, насаждающие в команде хороший стиль, хорошую архитектуру и прочая.
Ну, это безусловно. Поэтому я не верю восторженным "you cannot write wrong code" и прочему в таких презентациях.
J>Иначе да, все будет очень, очень плохо (не знаю, что там в Кларне, но верю на слово)
Ну, оно не прямо «ужас-ужас», но за многие куски кода хочется убивать на месте И в первую очередь — всяких «гуру»
Здравствуйте, Mamut, Вы писали:
M>Ну дык У нас пытались Haskell и OCaml на Эрланге писать
Я уж молчу, что на С++ пишут
J>>На коболе/бейсике/подставить-по-вкусу можно писать на любом языке, и именно нужны диктаторы, насаждающие в команде хороший стиль, хорошую архитектуру и прочая.
M>Ну, это безусловно. Поэтому я не верю восторженным "you cannot write wrong code" и прочему в таких презентациях.
А кто сказал, что кобол — это wrong code? Он не wrong, он просто так пахнет
Здравствуйте, jazzer, Вы писали:
J>К вопросу о том, что хаскель не нужен и это инструмент для гиков-энтузиастов и никто его в продакшене в здравом уме использовать не будет J>
J>In-house Haskell compiler: `Mu’. One of Lennart’s many Haskell compilers.
Мы совсем-совсем не гики-энтузиасты, но компилятор под себя запилим
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Wolverrum, Вы писали:
W>>Здравствуйте, jazzer,
W>>А как эти дифирамьы соотносятся с другим твоим постом
?
J>А как они должны соотноситься? J>Сорри, я не понимаю вопроса.
Ну как-то выглядит вполне себе противоречиво. Там — ленивость, утечки, рефакторинг кода: все это суть проблемы и попоболь. А тут "все просто работает", "few resources for manual tasks" (явно противоречие с проблемой рефакторинга) etc.
Здравствуйте, Wolverrum, Вы писали:
W>Ну как-то выглядит вполне себе противоречиво. Там — ленивость, утечки, рефакторинг кода: все это суть проблемы и попоболь. А тут "все просто работает", "few resources for manual tasks" (явно противоречие с проблемой рефакторинга) etc.
Ничего противоречивого.
Проблема с рефакторингом решается, как выяснилось, очень просто — через специальный режим компилятора, когда проверяется только то, что реально используется, а не всё на свете (примерно как мелкософтовский компилятор С++ не компилирует шаблоны вообще, пока ты их не используешь — даже синтаксис не проверяет).
Проблема с ленивостью решена в Standard Chartered опять же на уровне компилятора фактически отменой оной: Has a few language and runtime customizations: Largely strict(-ish) evaluation strategy (стр. 7 в презентации)
Здравствуйте, jazzer, Вы писали:
J>К вопросу о том, что хаскель не нужен и это инструмент для гиков-энтузиастов и никто его в продакшене в здравом уме использовать не будет
Haskell не нужен.
Главная проблема хаскелла и др. подобных языков что он игнорирует сложность. Это нормальный прагматичный подход для практиков. Но увы не лучший.
Лучший подход — создавать такие ЯП и tools которые делают сложные вещи простыми для понимания.
И такие tools существуют.
Здравствуйте, Wolverrum, Вы писали:
W>Здравствуйте, jazzer,
W>Спасибо, теперь вкурился: банк собственный диалект хаскеля юзает, и его нахваливает.
Где ты видишь диалект? Там лишь аспекты компиляции подкручены. Это как бэкэнд для любого другого языка — компилироваться в нейтив или в байткод, оптимизировать или нет (ленивость, в принципе, к оптимизации относится, а не к корректности), и т.п. В С/С++ все то же самое.
Изменений языка (что составило бы диалект) я у них не вижу.
ЗЫ Хотя даже если бы и был диалект — он что, перестал быть хаскелем? Это всего лишь будет означать, что есть такой очень полезный Хаскель, который рулит в Standard Chartered — и?
Здравствуйте, a_g_99, Вы писали:
__>Главная проблема хаскелла и др. подобных языков что он игнорирует сложность. Это нормальный прагматичный подход для практиков. Но увы не лучший. __>Лучший подход — создавать такие ЯП и tools которые делают сложные вещи простыми для понимания. __>И такие tools существуют.
Без детализации звучит как набор баззвордов, сорри.
Здравствуйте, Константин, Вы писали:
К>Здравствуйте, jazzer, Вы писали:
J>>К вопросу о том, что хаскель не нужен и это инструмент для гиков-энтузиастов и никто его в продакшене в здравом уме использовать не будет J>>
J>>In-house Haskell compiler: `Mu’. One of Lennart’s many Haskell compilers.
К>Мы совсем-совсем не гики-энтузиасты, но компилятор под себя запилим
Э-э-э, а какая связь? Айтишники в любой фирме должны быть гиками, иначе нафиг они нужны. Во многих конторах хачат GCC и собирают собственные его билды — и что теперь, С/С++ — для гиков на основании этого?
Мои слова про гиков относились к заказчикам (например, профессор в универе, для которого студент пишет эзотерическое исследование, или посетители конференций по теории типов). Банк в качестве заказчика — очевидно не гик.
Потому что им нужен delivery просто быстрее, чем в других банках. У нас релизы раз в неделю, все люди из банковской индустрии «как это так? как вы можете так часто релизить, шаманы!» 
