Спасибо, интересно. Тут же возникает вопрос: а как можно было бы сформулировать другую (но очень похожую) задачу, в которой решение и ответ Кэролла оказались бы корректными?
Предлагаю такую (в правильности не уверен, сейчас нет времени хорошо обдумать и проверить):
«Среди некоторого нечётного количества человек, случайно построенных в шеренгу, ровно один — рыжий. Какова предельная вероятность того, что он окажется ровно в середине шеренги, при неограниченном увеличении длины шеренги?»
И ещё одно соображение про «чистый код». Один из планов этого понятия — просто аккуратно выглядящий на мелком и среднем уровнях код, например — использование одной и той же идиомы в сходных контекстах, в которых она полезна. Далее, хорошо, если в данной среде программирования есть «единственно верный» (всеми признаный) кодекс аккуратности (детальные coding guidelines, каталог идиом), но часто его нет, или есть несколько конкурирующих. В такой обстановке код, «чисто» написанный одним сильным программистом, другому сильному программисту покажется грязным (это может привести к частичной переделке, которая сделает код общего проекта локально чистым, но с разных точек зрения, и глобально грязным с любой точки зрения). Типичный способ преодоления этой трудности — установление специфичных для проекта coding guidelines, плюс (если есть соответствующий инструментарий) регулярная автоматизированная проверка исходного кода (статический анализ) на соответствие этим правилам.
Подытоживая: отсутствие coding guidelines создаёт неоправданный риск «неумышленного» загрязнения кода даже вполне ответственными «чисто» программирующими разработчиками — но он относительно легко устраним заимствованием / компиляцией такого документа (такая работа, по идее, не слишком обременительна для «устремлённых» :) ).
Спасибо, прочитал с большим удовольствием. Ваш текст напомнил мне о давнем, до сих пор не реализованном намереньи прочитать The Programmer's Stone. Правда, мне показалось, что последняя часть вашего рассмотрения («устремлённый») не вполне продолжает противопоставление «грязный-чистый»: например, неустремлённый программист (тот, который «не достигает вершины своего изначального потенциала» и работает строго по спецификациям в знакомой области) может производить очень чистый код. И наоборот, устремлённый супер-производительный «хакер» (в хорошем смысле :) ) может продвинуть сложный проект так, как никто другой, но при этом произведя не особо чистый код (например, натащив какого-нибудь «прогрессивного новья», интересного ему в данный момент, но не полезного проекту в долгосрочной перспективе); т.е. противопоставление неустремлённый / устремлённый не вполне коррелирует с противпоставлением производитель грязного / производитель чистого кода. Это неможко смазывает посыл сообщения, по-моему.
Спасибо, интересно, но вот тут: " Синтаксис TypeScript — подмножество синтаксиса EcmaScript 5 (ES5) " я бы рекомендовал подправить (superset — надмножество или, более по-русски, надстройка или расширение… по ряду пунктов совместимое с проектом стандарта EcmaScript 6, но выходящее за его пределы).
Предлагаю такую (в правильности не уверен, сейчас нет времени хорошо обдумать и проверить):
«Среди некоторого нечётного количества человек, случайно построенных в шеренгу, ровно один — рыжий. Какова предельная вероятность того, что он окажется ровно в середине шеренги, при неограниченном увеличении длины шеренги?»
И ещё одно соображение про «чистый код». Один из планов этого понятия — просто аккуратно выглядящий на мелком и среднем уровнях код, например — использование одной и той же идиомы в сходных контекстах, в которых она полезна. Далее, хорошо, если в данной среде программирования есть «единственно верный» (всеми признаный) кодекс аккуратности (детальные coding guidelines, каталог идиом), но часто его нет, или есть несколько конкурирующих. В такой обстановке код, «чисто» написанный одним сильным программистом, другому сильному программисту покажется грязным (это может привести к частичной переделке, которая сделает код общего проекта локально чистым, но с разных точек зрения, и глобально грязным с любой точки зрения). Типичный способ преодоления этой трудности — установление специфичных для проекта coding guidelines, плюс (если есть соответствующий инструментарий) регулярная автоматизированная проверка исходного кода (статический анализ) на соответствие этим правилам.
Подытоживая: отсутствие coding guidelines создаёт неоправданный риск «неумышленного» загрязнения кода даже вполне ответственными «чисто» программирующими разработчиками — но он относительно легко устраним заимствованием / компиляцией такого документа (такая работа, по идее, не слишком обременительна для «устремлённых» :) ).