Прим. перев.: Это перевод истории о том, как нелегко оказалось написать параллельную быструю сортировку (quicksort) на Хаскеле. Оригинал статьи написан в 2010 году, но, мне кажется, он до сих пор поучительный и во многом актуальный.
Есть много примеров того, как Хаскель делает простые проблемы сложными. Вероятно, самый известный из них—это решето Эратосфена, которое легко написать на любом императивном языке, но настолько сложно написать на Хаскеле, что почти все решения, которые преподавались в университетах и использовались в исследованиях последние 18 лет, оказались неправильными. На их несостоятельность обратила внимание Мелисса О'Нил [Melissa O'Neill] в своей важной научной работе "Настоящее решето Эратосфена". В ней приводится прекрасное описание того, что не так в старых подходах, и как их надо исправить. Решением Мелиссы было использовать очередь с приоритетом [priority queue] для реализации решета. Правильное решение оказалось в 10 раз длиннее, чем намного более простое решение на F# и в целых 100 раз длиннее, чем оригинальный изуродованный алгоритм на Хаскеле.
От автора: переводстатьи «Функциональное программирование непопулярно, потому что оно странное» вызвал бурное обсуждение. В нескольких комментариях весьма справедливо замечалось, что при обсуждении недостатков функционального программирования хорошо бы опираться на современные и развитые функциональные языки (в оригинальной статье примеры были на шаблонах C++) и что Хаскель, например, последние пять лет широко используется в индустрии. В связи с этим я хотел бы обратить внимание на две очень предметные статьи из другого блога (от автора книги F# for Scientists): (i) "Недостатки чистого функционального программирования" и (ii) "Почему Хаскель так мало используется в индустрии". Перевод первой из них я как раз и хотел бы представить ниже.
1. На чистых функциональных языках не существует эффективного неупорядоченного словаря и множества
Я знаю людей, которые искренне недоумевают по поводу того, что функциональное программирование не очень популярно. К примеру, сейчас я читаю книжку «Из смоляной ямы» (Out of the Tar Pit), в которой авторы после аргументов в пользу функционального программирования говорят:
В этой статье я кратко расскажу, как именно преобразуются координаты точек при повороте камеры в 3D играх, css-преобразованиях и вообще везде, где есть какие-то вращения камеры или предметов в пространстве. По совместительству это будет кратким введением в линейную алгебру: читатель узнает, что такое (на самом деле) вектор, скалярное произведение и, наконец, матрица поворота.
Моделирование извержения вулкана
с помощью Lattice Boltzmann Method. (с) Источник
В этой статье я расскажу о численном методе моделирования гидродинамики Lattice Boltzmann Method, LBM. На русском—метод решёточных уравнений Больцмана. Он превосходит другие известные методы (например, finite element method) в легкости распараллеливания, возможности моделирования многофазных потоков, моделировании потоков в пористых средах. Кроме того, вычислительный алгоритм содержит только простейшие арифметические операции. Метод весьма новый, первые коммерческие продукты на его основе стали появляться около 2010 года.
В этой короткой заметке я хотел бы систематизировать (а именно, расположить в иерархию) многие популярные принципы проектирования программных приложений (test-driven development, ООП, SOLID и т. д.), а также рассмотреть следствия из этой иерархии.
В частности, такая иерархия (я надеюсь) позволит лучше расставлять приоритеты в разработке и профессиональном росте, лучше понимать старые технологии и быстрее изучать новые. При появлении новой парадигмы разработки (a la test-driven development) вы сможете быстро включить ее в эту иерархию и, следовательно, быстрее понять, из каких принципов исходили создатели парадигмы и как правильно ее использовать. Новичкам в программировании статья может быть полезна как обзор существующих принципов.
И в качестве самого базового я полагаю разумным считать принцип «управления сложностью/минимизации технической сложности» МакКоннела. А самыми важными срествами минимизации сложности являются модульность и абстракция.
Вы никогда не задумывались над тем, что навигация в Windows могла бы быть намного удобней? Почему бы не добавить возможность, аналогичную навигации по классам во многих современных IDE, когда в выпадающем списке, вызываемом сочетанием клавиш, отображаются папки с нужным именем, вот так:
В этой короткой заметке хочу рассказать о прекрасной программе для поиска утечек памяти под Visual Studio--Visual Leak Detector.
Она удивительно проста в использовании и выдает подробную информацию о найденных утечках, а на хабре пока не упоминалась.
Хочу поделиться с сообществом открытой недавно для самого себя новой IDE от JetBrains—WebStorm, оказавшейся просто превосходной, и сравнить ее с Visual Studio в плане редактирования Javascript.
Disclaimer: пост в основном рассчитан на тех разработчиков, которые работают в стеке .Net и обычно не в курсе того, что есть другие IDE, намного более подходящие для некоторых задач, чем Visual Studio.
Это продолжение заметки о том, почему юнит-тесты плохо работают в научных приложениях; и в этой статье я хочу рассказать о трудностях поиска ошибок и дебага (научных приложений), с которыми в свое время столкнулся, и многие из которых были удивительными для меня как веб-разработчика.
В этой статье я хочу поделиться своим опытом разработки научных приложений, и рассказать, почему Test-Driven Development и юнит-тесты не являются панацеей, как принято считать в последнее время, по крайней мере с точки зрения нахождения программных ошибок. Почему же?
