Записки программиста

Время от времени люди говорят мне, что я что-то делаю не по стандарту, и потому неправ. Дескать, «твоя реализация протокола не соответствует RFC» или «почему ты пишешь void main(), когда по стандарту должно быть int main()»? Меня давно подмывало написать пост на эту тему, и вот, после очередного такого упрека, я собрался с духом.

В последнее время все больше людей выбирают языки программирования с динамической типизацией. Сторонники динамической типизации утверждают, что на изучение Erlang’а требуется две недели, после чего можно сразу начать писать боевой код. Что все равно интернеты динамически типизированы, что ошибки типизации быстро находятся и легко устраняются, а настоящую проблему представляют сложные логические ошибки, где статическая типизация все равно не помогла бы. Что статическая типизация — это медленно и скучно, а на Clojure можно легко написать свой Mortal Kombat за два вечера. Давайте же выясним, почему на самом деле вы не должны хотеть динамической типизации.

Сказать по правде, я долгое время не понимал, для чего нужны DSL. В конце концов, всю жизнь без них как-то обходился, и нормально. Какую проблему, спрашивается, они решают? И вообще, у нас тут безо всяких DSL сплошь и рядом зоопарки языков программирования, а вы предлагаете ввести еще один язык!? Но, подумав, поспрашивав людей и погуглив немного, я пришел к выводу, что в ряде случаев создание собственных DSL может быть хорошей идеей. Проще всего убедиться в этом, рассмотрев несколько практических задач и как они решаются с использованием DSL.

Вот многие программисты считают себя умными. Читают Хабр, слушают Радио-Т, рассуждают с умным видом про шаблоны ООП или там теории категорий. И любят делать умные решения. Ведь простые решения любая обезьянка написать может, а вот сложные… Почитывая мой бложик, кто-то из вас мог ошибочно подумать, что я тоже такой весь из себя шибко умный. Знаю там Haskell, книжек много читаю. В действительности, я очень глупый. И поэтому при решении задач стараюсь использовать как можно более простые решения.

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

Будучи молодым и наивным, я хотел перепробовать на практике все новомодные NoSQL-решения, знать все необычные языки программирования и писать код, покрытый тестами не менее, чем на 98%. Я считал, что при желании смогу одинаково хорошо разбираться как в веб-разработке, так и в написании драйверов для FreeBSD. Теперь, состарившись и помудрев, я начинаю осознавать всю глубину этих, а также других заблуждений. В данной серии заметок я хочу перечислить совершенно очевидные вещи, понимание которых, тем не менее, почему-то приходит только со временем.

Непрерывная интеграция (continuous integration) — это очень, очень хорошо. Вы настраиваете ее один раз, и ваши волосы моментально становятся гладкими и шелковистыми. В этой заметке будет показано, как просто происходит установка и настройка системы непрерывной интеграции Jenkins.

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

Программисты постоянно занимаются оптимизацией программ. Это такая же неотъемлемая часть работы, как исправление багов или рефакторинг. Обычно, говоря «оптимизация», мы имеем в виду ускорение программы. Несмотря на то, что под оптимизацией также может пониматься уменьшение объема используемой оперативной памяти или иных ресурсов (скажем, сетевого трафика или заряда батареи), в данной заметке речь пойдет именно об ускорении.

Недавно мне пришло одно интересное письмо. Автор интересовался, что нужно делать, чтобы стать программистом. С чего начать, какой язык программирования осваивать в первую очередь, и так далее. Мне кажется, это очень занятный вопрос, и сегодня я постараюсь обрисовать свое видение сей проблемы.