Paul Graham: Superlinear returns
(c) DALL-E: "Vrubel painting of a blogger crying with admiration while reading an essay by another, more experienced, author." DALL-E отказывается рисовать по запросам с именами.
Рекомендую эссе Paul Graham: Superlinear returns.
Что мне нравится в текстах Paul Graham так это опережение моих писательских планов. Пол периодически пишет про то, что я давно хочу написать, но пока не могу — ещё не Paul Graham :-D
Конкретно на тему нелинейных изменений я уже лет 10 хочу написать эссе да побольше. Но если бы я сел его писать сейчас, то это был бы длиннопост со странными графиками и терминами и без таких интересных примеров как у Пола. Поэтому приходится давать ссылки на его эссе.
Дальше, в общем-то, можете мой пост не читать. Главное оригинальное эссе прочтите. Но оставлю пару заметок для истории, которые лучше читать после оригинального эссе.
Верификация частными случаями
Буду говорить в контексте программирования, но соображения можно распространить шире.
Когда мы описываем алгоритм: программу, доказательство теоремы или решение математической задачи — мы строим его описание в рамках некоторой формальной модели. В рамках соглашений и ограничений, которые мы явно или неявно принимаем.
Описать алгоритм вне формальной модели невозможно. Хотя бы потому, что любой язык — уже формализация.
Отсюда вытекает интересная проблема.
Верификация через дублирование логики
Привет.
В посте Тесты, которые тестируют тесты я описал свой взгляд на верификацию программ через дублирование их логики в виде отдельной модели и последующее сравнение с ней. В качестве частного случая выступили юнит-тесты.
В этот раз, опираясь на изложенные идеи, я попробую сформулировать общий подход к оценке уровня верифицированности ПО.
Зачем нужен план
Самый известный план на планете
Сначала я хотел назвать этот текст «Зачем нужен бизнес-план», но к чему себя ограничивать? План — он и в Африке план, не важно для чего. Тот, что для бизнеса, называется бизнес-планом. Тот, что для эвакуации, называется, как ни странно, планом эвакуации. И так далее.
Но идея текста таки пришла из области, где актуальны бизнес-планы. Часто стал встречаться с высказываниями о том, что «бизнес-план, конечно, нужен, но вот конкретно в нашем случае он пользу не принесёт потому, что»:
- у нас слишком большая неопределённость, будет гадание на кофейной гуще;
- и так всё предельно ясно, план — лишняя трата сил.
Сам я тоже страдал этими тараканами, но так получилось, что периодически разного рода планы составлять всё-таки приходилось. И хочу вам сказать — планы делать полезно и нужно.
Но сначала…
Почему разработчики не сделают эту простую штуку?
Животрепещущий вопрос, не правда ли?
Меня уже 3 года как им пытают персонально, поэтому я решил попытаться рассказать всё-таки почему. Рассказывать, конечно, буду со стороны разработчика-одиночки. В командах побольше есть некоторые нюансы, но суть та же.
Для затравки приведу небольшую иллюстрацию, смысл её, думаю, понятен.
Взгляд на проект со стороны пользователя и разработчика.