0 added
0 removed
Original
2026-01-01
Modified
2026-02-26
1
<p><em>Это перевод<a>статьи</a>Даниэля Лебреро, которая также была опубликована на<a>dev.to</a>(там в комментариях есть интересное обсуждение на английском).</em></p>
1
<p><em>Это перевод<a>статьи</a>Даниэля Лебреро, которая также была опубликована на<a>dev.to</a>(там в комментариях есть интересное обсуждение на английском).</em></p>
2
<p>Меня удивил дядюшка Боб в<a>посте</a>под названием: "Type Wars". Он пишет: "Так что я предполагаю, что чем более общепринятой необходимостью профессиональной дисциплины будет становится TDD, тем более предпочтительными будут становится динамические языки. Smalltalker'ы постепенно победят".</p>
2
<p>Меня удивил дядюшка Боб в<a>посте</a>под названием: "Type Wars". Он пишет: "Так что я предполагаю, что чем более общепринятой необходимостью профессиональной дисциплины будет становится TDD, тем более предпочтительными будут становится динамические языки. Smalltalker'ы постепенно победят".</p>
3
<p>Это утверждение не<a>всем пришлось по душе</a>. В сообществе сторонников статически-типизированных языков многие высказались, что достаточно продвинутая система типов (и типы - как доказательства) делает юнит-тесты ненужными. Haskell даже<a>утверждает</a>, что "если скомпилировалось, то обычно работает".</p>
3
<p>Это утверждение не<a>всем пришлось по душе</a>. В сообществе сторонников статически-типизированных языков многие высказались, что достаточно продвинутая система типов (и типы - как доказательства) делает юнит-тесты ненужными. Haskell даже<a>утверждает</a>, что "если скомпилировалось, то обычно работает".</p>
4
<p>Будь это уменьшение багов, улучшенное документирование, более продвинутая поддержка IDE или простота понимания, для меня все это означает одно обещание: меньше багов.</p>
4
<p>Будь это уменьшение багов, улучшенное документирование, более продвинутая поддержка IDE или простота понимания, для меня все это означает одно обещание: меньше багов.</p>
5
<p>А я ненавижу баги. Я считаю, что баги - одно из худших сжирателей времени и энергии в проекте. Нет ничего, что раздражает меня сильнее, чем слышать в демо в конце итерации гордое "мы сделали Х стори-пойнтов и исправили 20 багов! Ура!".</p>
5
<p>А я ненавижу баги. Я считаю, что баги - одно из худших сжирателей времени и энергии в проекте. Нет ничего, что раздражает меня сильнее, чем слышать в демо в конце итерации гордое "мы сделали Х стори-пойнтов и исправили 20 багов! Ура!".</p>
6
<p>По мне так это звучит как "В прошлой итерации мы написали более 20 багов, но наши клиенты смогли найти лишь 20! И нам заплатили и за их написание, и за их исправление. Ура!"</p>
6
<p>По мне так это звучит как "В прошлой итерации мы написали более 20 багов, но наши клиенты смогли найти лишь 20! И нам заплатили и за их написание, и за их исправление. Ура!"</p>
7
<h3>Баги в графиках</h3>
7
<h3>Баги в графиках</h3>
8
<p>С этим на уме, я попробовал найти какое-то эмпирическое основание идее "меньше багов в статических языках". К сожалению,<a>лучший найденный мною источник</a>говорит, что все очень плохо. Так что я согласился на более наивный способ: поиск в Github'е.</p>
8
<p>С этим на уме, я попробовал найти какое-то эмпирическое основание идее "меньше багов в статических языках". К сожалению,<a>лучший найденный мною источник</a>говорит, что все очень плохо. Так что я согласился на более наивный способ: поиск в Github'е.</p>
9
<p>Вот несколько графиков сравнения числа issues с тегом "bug" и числа репозиториев на Github по разным языкам. Я постарался избавиться от шума, используя только репозитории с некоторым количеством звездочек (star), с допущением, что если нет звездочек, значит кодом никто не пользуется, и баги, соответственно, никто не находит.</p>
9
<p>Вот несколько графиков сравнения числа issues с тегом "bug" и числа репозиториев на Github по разным языкам. Я постарался избавиться от шума, используя только репозитории с некоторым количеством звездочек (star), с допущением, что если нет звездочек, значит кодом никто не пользуется, и баги, соответственно, никто не находит.</p>
10
<p>Зеленый цвет - крутые, продвинутые статически-типизированные языки: Haskell, Scala and F#. Оранжевый - "старые и скучные" статически-типизированные языки: Java, C++ and Go. Красный - динамически-типизированные языки: JavaScript, Ruby, Python, Clojure and Erlang.</p>
10
<p>Зеленый цвет - крутые, продвинутые статически-типизированные языки: Haskell, Scala and F#. Оранжевый - "старые и скучные" статически-типизированные языки: Java, C++ and Go. Красный - динамически-типизированные языки: JavaScript, Ruby, Python, Clojure and Erlang.</p>
11
<p><strong>Раунд 1.</strong>Языки отсортированы по багам. Все репозитории.</p>
11
<p><strong>Раунд 1.</strong>Языки отсортированы по багам. Все репозитории.</p>
12
<p><strong>Раунд 2.</strong>Языки отсортированы по багам. Репозитории с 10+ звезд.</p>
12
<p><strong>Раунд 2.</strong>Языки отсортированы по багам. Репозитории с 10+ звезд.</p>
13
<p><strong>Раунд 3.</strong>Языки отсортированы по багам. Репозитории с 100+ звезд.</p>
13
<p><strong>Раунд 3.</strong>Языки отсортированы по багам. Репозитории с 100+ звезд.</p>
14
<p>Ничего нельзя утверждать, но<strong>сильно тревожит отсутствие какого-либо подтверждения меньшему количеству багов в продвинутых статических языках</strong>.</p>
14
<p>Ничего нельзя утверждать, но<strong>сильно тревожит отсутствие какого-либо подтверждения меньшему количеству багов в продвинутых статических языках</strong>.</p>
15
<h3>Проблема не в Static vs Dynamic</h3>
15
<h3>Проблема не в Static vs Dynamic</h3>
16
<p>Графики показывают отсутствие корреляции между статичностью-динамичностью и багами. Но показывают (как минимум, по моему скромному мнению) пропасть между языками, фокусирующимися на простоте, и всеми остальными.</p>
16
<p>Графики показывают отсутствие корреляции между статичностью-динамичностью и багами. Но показывают (как минимум, по моему скромному мнению) пропасть между языками, фокусирующимися на простоте, и всеми остальными.</p>
17
<p>И<a>Роб Пайк</a>(создатель Go) и<a>Рич Хики</a>(создатель Clojure) проводили классные лекции о простоте как фундаментальной части своих языков.</p>
17
<p>И<a>Роб Пайк</a>(создатель Go) и<a>Рич Хики</a>(создатель Clojure) проводили классные лекции о простоте как фундаментальной части своих языков.</p>
18
<p>И эта простота означает, что приложения легче понимать, легче изменять, легче поддерживать. Код - более гибкий. И все это означает меньше багов.</p>
18
<p>И эта простота означает, что приложения легче понимать, легче изменять, легче поддерживать. Код - более гибкий. И все это означает меньше багов.</p>
19
<p>Что характеризует простой язык? Вот штуки, присущие Go, Erlang и Clojure:</p>
19
<p>Что характеризует простой язык? Вот штуки, присущие Go, Erlang и Clojure:</p>
20
<ul><li>Нет ручного менеджмента памяти</li>
20
<ul><li>Нет ручного менеджмента памяти</li>
21
<li>Нет параллельности, основанной на mutex'ах</li>
21
<li>Нет параллельности, основанной на mutex'ах</li>
22
<li>Нет классов</li>
22
<li>Нет классов</li>
23
<li>Нет наследования</li>
23
<li>Нет наследования</li>
24
<li>Нет сложной системы типизации</li>
24
<li>Нет сложной системы типизации</li>
25
<li>Нет мультипарадигм</li>
25
<li>Нет мультипарадигм</li>
26
<li>Не очень много синтаксиса</li>
26
<li>Не очень много синтаксиса</li>
27
<li>Не академичный</li>
27
<li>Не академичный</li>
28
</ul><p>Может, все эти модные штуки в наших языках на самом деле являются острыми инструментами, которыми мы раним себя - создаем баги и тратим время. И на самом деле они вносят кучу дополнительной сложности, а в реальности нам нужен более простой язык.</p>
28
</ul><p>Может, все эти модные штуки в наших языках на самом деле являются острыми инструментами, которыми мы раним себя - создаем баги и тратим время. И на самом деле они вносят кучу дополнительной сложности, а в реальности нам нужен более простой язык.</p>
29
<p>Как<a>сказал</a>Тони Хоар:</p>
29
<p>Как<a>сказал</a>Тони Хоар:</p>
30
<blockquote><p>Есть два способа проработки дизайна приложения: один - сделать все настолько простым, что, очевидно, нет недостатков. Второй способ - сделать все настолько сложным, что нет очевидных недостатков.</p>
30
<blockquote><p>Есть два способа проработки дизайна приложения: один - сделать все настолько простым, что, очевидно, нет недостатков. Второй способ - сделать все настолько сложным, что нет очевидных недостатков.</p>
31
</blockquote><p><em>Перевод: Рахим Давлеткалиев</em></p>
31
</blockquote><p><em>Перевод: Рахим Давлеткалиев</em></p>
32
<p>P.S.<a>Урок</a>про типизацию из курса "<a>Введение в программирование</a>"</p>
32
<p>P.S.<a>Урок</a>про типизацию из курса "<a>Введение в программирование</a>"</p>
33
33