| +66 голосов |
|
Для «чистоты мысленного эксперимента» вычеркнем разработчиков наукоёмкого ПО из списка – хотя бы потому, что по спецификациям можно писать любые программы, включая и очень наукоёмкие, и при этом не иметь понятия о прикладной области.
Будем рассматривать простую задачу. Очень простую и обыденную.
Перед системным программистом, в свою очередь, уже совсем иные виды – его волнует протокол обмена клавиатуры, в которую встроена кнопка, но он всё равно не видит собственно процесса её нажатия, а только проявление этого процесса – некое сообщение в установленном протоколом формате, подтверждающее тот факт, что кнопка точно была нажата.
Я два раза употребил слово «точно» и выделил его не случайно. Потому что замыкание контактов кнопки на самом деле… является очень непростым процессом, и характеризуется таким явлением, как «дребезг» (contact bounce).
Так что для быстрой электроники, к которой подсоединён механический выключатель (кнопка), процесс его замыкания является последовательностью импульсов разной и случайной продолжительности, после которой, собственно, и формируется контакт. Для борьбы с дребезгом придумали много всяких аппаратных и программных ухищрений, но аппаратные неэкономичны, а программные не всегда гарантируют, что контакт был точно замкнут.
Естественно, виден этот процесс работающему на самом нижнем уровне программисту. И если его более высокоуровневым коллегам математика при решении задачи определения нажатия кнопки была не нужна, то здесь случай особый. Потому что без знания математики, причём серьёзной математики, сразу нескольких её прикладных областей, решить задачку красивого и качественного устранения «дребезга» весьма непросто. Зато если знать теорию электронных цепей, аналоговой и цифровой фильтрации, можно написать рекуррентную формулу цифрового фильтра (для знающих электронику – выполняющего роль триггера Шмитта:
Такой фильтр реализуется буквально двумя десятками команд современного микроконтроллера и отнимает примерно столько же машинных тактов.
Як RPA-платформа допомогла SkyUр автоматизувати оплату рахунків
| +66 голосов |
|
Абсолютно с вами согласен. На каждом уровне иерархии существуют свои сложности и существует своя "глава" прикладной математики. И в какой-то мере, от специалистов занимающимися проектированием протоколов и созданием железа требуются более глубокие теоретические знания. Во-первых, как вы правильно заметили, все задачи на уровне железа требуют от инженера ясного понимания физики, которая кроется за тем или иным процессом. Во-вторых, изобретения и продукты, основанные на их решениях и выводах, должны быть очень надежными - слишком многое зависит от качественной работы этих вещей.
Тем неменее, иногда инженерам недостаточно просто знать точки подключения протокала "под ними". Например, компьютерные системы для самолётов или военное программное обеспечение. Абстракция помогает, по-моему, только на начальной стадии программирования, когда главная цель - создать рабочее решение проблемы. Далее, когда речь заходит об надежности в экстримальный условиях, быстродействии, совместимости, "дальновидности кода" и т.д. программист невольно спускается вниз по иерархии Computer Architecture.
Например, от ветеранов то и слышишь, что раньше "работали не на решение, а на лучшее решение". Потому что машины были намного слабее и тут программисту было непозволительно забывать о некоторых низкоуровневых вещах и о теории. Сейчас вещи обстоят иначе, но иногда это вредит программистам.