О математике и программировании

Это так, - всего лишь попытка осмысления, не более того.

Для «чистоты мысленного эксперимента» вычеркнем разработчиков наукоёмкого ПО из списка – хотя бы потому, что по спецификациям можно писать любые программы, включая и очень наукоёмкие, и при этом не иметь понятия о прикладной области.

Будем рассматривать простую задачу. Очень простую и обыденную.

Предположим, есть некая механическая кнопка, связанная с контактом, состояние которого  (замкнут-разомкнут) надо прочитать из программы. Например, - кнопка клавиатуры.

Кодировщик, «пасущийся» на вершине программно-аппаратных архитектур, решает эту задачу теми средствами, которые для него оставлены на поверхности. А именно, - с помощью соответствующего API в рамках реализованной архитектурной модели. К слову, - выбор этих моделей невелик: или это нечто мониторно-примитивное, вынуждающее кодировщика самостоятельно опрашивать состояние кнопки каким-то вызовом, назовём его ReadKeyState(), или это традиционная для современных ОС модель просмотра очереди сообщений о событиях, или же более редкая модель назначения определяемых кодировщиком обработчиков разных событий. Вне зависимости от модели, для кодировщика нажатие кнопки – процесс невидимый, точнее, - существующий не как процесс, а только как проявление, свидетельствующее о том, что кнопка точно была нажата.

 

Перед системным программистом, в свою очередь, уже совсем иные виды – его волнует протокол обмена клавиатуры, в которую встроена кнопка, но он всё равно не видит собственно процесса её нажатия, а только проявление этого процесса – некое сообщение в установленном протоколом формате, подтверждающее тот факт, что кнопка точно была нажата.

Я два раза употребил слово «точно» и выделил его не случайно. Потому что замыкание контактов кнопки на самом деле… является очень непростым процессом, и характеризуется таким явлением, как «дребезг» (contact bounce).

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

Естественно, виден этот процесс работающему на самом нижнем уровне программисту. И если его более высокоуровневым коллегам математика при решении задачи определения нажатия кнопки была не нужна, то здесь случай особый. Потому что без знания математики, причём серьёзной математики, сразу нескольких её прикладных областей, решить задачку красивого и качественного устранения «дребезга» весьма непросто. Зато если знать теорию электронных цепей, аналоговой и цифровой фильтрации, можно написать рекуррентную формулу цифрового фильтра (для знающих электронику – выполняющего роль триггера Шмитта:

Такой фильтр реализуется буквально двумя десятками команд современного микроконтроллера и отнимает примерно столько же машинных тактов.

Вот так примерно и получается, - прикладная область навязывает требования к программисту, и надо знать свой уровень абстракции: кодировщикам – языково-библиотечно-инструментальный, системным программистам – спецификации и протоколы, embedded-программистам («железячникам») – специфику физические объектов, принципов обработки сигналов, математическую статистику, теорию систем etc.