НовостиСобытияКонференцииФорумыIT@Work
Идеи и практики автоматизации:

Блог

Взломает ли АНБ AES

Сергей Бобровский
17.04.2012 10:41:46

Одна из главных причин спроса именно на Haskell в алгоритмически сложных проектах -- это то, что Haskell представляет собой отличную абстрактную платформу для создания предметно-ориентированных DSL-языков. В результате объем программы, написанной на каком-нибудь императивном языке, с помощью Haskell потенциально можно сократить в сотни раз (об этой технологии был пост "Тысячекратная компактность кода").

Но при этом у Haskell есть и немало оппонентов, которые отмечают его слабые стороны -- и что интересно, минусы Хаскела, озвученные практиками, едва ли не полностью противоположны красивостям, нарисованным Andy Adams-Moran в eWeek (см. вчерашний пост).
Примерно передам эти мнения: компактность кода приводит к ужасающему синтаксису; монады призваны формализовать побочные эффекты, однако сама возможность их использования снижает общую надежность программы; запутанность многих программных механизмов; кошмарность зависимостей между пакетами; стандартные библиотеки не такие уж и целостные…
А уж сложность доступа и редактирования вложенных полей хаскеловскому коммьюнити известна очень хорошо и очень давно, однако проходят годы, и несмотря на уверения Adams-Moran, проблема эта никак не решается.

Ленивые/отложенные вычисления -- также вещь обоюдоострая. А главное, что проблемы с ними начинают особенно остро проявляться, когда проект становится большим. Тогда у разработчиков будут улетать дни и дни на тюнинг этого механизма под нужную задачу. А ведь отладка его совсем не тривиальна. В результате же преимущества "ленивого" подхода нивелируются большими проблемами с общей эффективностью системы.

Резюме по Хаскелу приверженцы этого языка формулируют так: Haskell делает простые вещи сложными, а сложные вещи -- простыми.

Кстати, развернутую, но доброжелательную критику Хаскела давно ведет в своем блоге профессор Роберт Харпер из Карнеги-Меллона, и силами энтузиаста Владислава Натарова этот блог переведен на русский. Любители функционального программирования, почитайте обязательно, очень интересно!

То есть если не стоит задача оптимизации системы в сотни и тысячи раз, лучше пользоваться "более классическими" языками. Но вот когда надо решить узкоспециализированную задачу, лучше всего помогут, пожалуй, мощные функциональные языки. К такой задаче, кстати, следует отнести обещание Агентства национальной безопасности США взломать алгоритм AES.
Эксперты полагают, что классическая криптоатака на этот алгоритм пока обречена на неудачу, слишком много требуется машинного времени и ОЗУ на такой взлом, и вряд ли в ближайшие десять лет ситуация изменится. Но вполне возможна успешная атака на реализации этого алгоритма (поиск сторонних каналов, анализ схем генерации ключей, использование слабостей генератора случайных чисел, плохие пароли, …), на конечные точки в системе связи, на уязвимости программного кода (что делает особо актуальными DSL-языки, упрощающие автоматическую генерацию кода) итп.
Кроме того, АНБ готовит аппаратные системы взлома ключей RSA-1024, и реализация соответствующих алгоритмов на машинном уровне например на Хаскеле может быть одной из самых оптимальных.

Кстати, интересное сравнение темпов взлома конкретного ключа RSA-1024 любительской(!) системой -- от 6 лет в 2011-м до 10 минут в 2013-м.

Далее -- есть ли альтернативы Хаскелу?

Комментариев: 6

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

Дмитрий
18.04.2012 01:41:47

Желтушный заголовок.
Много воды, пережеванных мифов, мало конкретных деталей.
Вера в чудеса (1000-кратное сокращение кода).
Ага, давайте полноценный аналог MS Office с объемом кода в 1000 строк.

> сама возможность их использования снижает общую надежность программы
Можно примеры того, как использование монад снижает надежность программы по сравнению с ... кстати, по сравнению с чем?

> оптимизации системы в сотни и тысячи раз
оптимизации по какому критерию?

> проблемы с ними начинают особенно остро проявляться, когда проект становится большим
а конкретные примеры есть? пока что встречал только положительное влияние нестрогой семантики на объемы кода и его переиспользование. http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CC4QFjAA&url=http%­3A%2F%2Fwww.cs.kent.ac.uk%2Fpeople%2Fstaff%2Fdat%2Fmiranda%2Fwhyfp90.pdf&ei=QeONT_2iDcmeOvPU8O4K&usg=AFQjCNEBbTAPkPRho_ATUFuAP0hT­NlOQlA

> Реализация соответствующих алгоритмов на машинном уровне например на Хаскеле
Ага, это вообще ПУШКА. У нас появились аппаратную интерпретацию Хаскеля? Можно ссылки, пожалуйста?

dmz
18.04.2012 06:47:16


Монады не призваны "формализовать" побочные эффекты. Монада IO --- частный случай.

Проблемы именно с ленивостью на практике возникают нечасто и ловятся быстро, независимо от размера проекта.

Альтернатив хаскеллу, как высокоуровневому компилируемому в нативный код статически типизированному функциональному, обладающему развитой системой типов, живому и активо развивающемуся языку с достаточно обширным набором библиотек --- на текущий момент нет.

Аноним
18.04.2012 08:37:13

Боже мой, что я только что прочитал?

Игорь
20.04.2012 11:59:53

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

4k
01.05.2012 09:27:46

> Монады

Монады делают программирование по сути императивным. Какой смысл на Хаскел переходить тогда?
Да, те куски которые без них, смотрятся поначалу более абстрактно и алгебраически но тут вступает в игру ленивость.

> Ленивость

Ленивость для понимания программы увы требует понимания подкапотной механики Хаскеля.
Опять - же, в чем тогда предполагалось упрощение и облегчение по сравнению с императивными
языками? А раз тоже сложно, зачем тогда Хаскел? Абстрагироваться то в достаточной степени
от механики не удалось, преимущества ФП не реализовались?
Хаскел НЕ дает того облегчения параллелизма и многого прочего что обещал.
И как раз ленивость все и усложняет вопреки обещаниям.
Старички вспомнят возможно похожую историю с Прологом и его недетерминизмом.
Тоже ведь - типа декларативный, программа умеет считать больше чем планировалось
и так далее. Маркетинг. Хаскель - это просто новый чудо-вариант Пролога?
Нет, языки со сложными внутренними механизмами не приживаются в массах, имхо.
У них есть своя ниша но программы на них более непредсказуемы и тяжелее
поддерживаются. Статическая типизация тут не спасет - все равно по определению
больше комбинаторных вариантов путей исполнения программы и модифицировать
так чтоб все они продолжали работать - сложнее.

> Альтернатив хаскеллу

МЛ семейство языков ничуть не хуже Хаскеля. Только не стоит искать в нем фичи Хаскеля, это глупо.
В нем свои подходы и свои решения своих проблем. По факту - вполне юзабельно.

4k
01.05.2012 10:01:40

> ООП

именно так, все слова тут правда. Конечно, внедряльщики ООП в свое время громко кричали и писали что все как раз наоборот. но... "хоть сто раз скажи - халва! во рту слаще не станет". ведь они просто зарабатывали на этом. а хитрые программисты "зарабатывали" потом на платной поддержке сложных ООП программ)) ООП - это методика механического доения заказчика.

если не лениться обдумать эти обещания то:

1) Наследование по самому своему определению нарушает модульность, в одну сторону.
Поскольку контракт между родителем и потомком не выписан явно, по этому каналу
могут бродить неожиданные сюрпризы при модификациях))

2) посыл сообщения это как goto, эта абстракция может быть использована конечно но она
ничем не облегчает разработку и поддержку параллельных программ, как не облегчал и goto
обычные ассемблерные программы.
никакого контроля схем взаимодействия при модификациях, кроме ручного.
и вполне естественно, быстрее получается бардак, как в ассемблере по сравнению с паскалем.

да и вообще - те кто хоть раз в жизни писал параллельные программы (например, я),
знает что основная задача распараллеливания как раз развязывание зависимостей и состояний.
передача сообщения есть синхронизация состояний. чем больше синхронизаций тем меньше
коэффициент распараллеливания.

поэтому параллельщики всегда пишут для себя либы со своими абстракциями для параллелизма.
и потом уже в программах только их используют, не лазя внутрь и не меняя схемы обмена сообщениями.

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