Прочитал недавно известную книгу Ф. Брукса «Мифический человеко-месяц». А сегодня в комментариях у ![[info]](http://stat.livejournal.com/img/userinfo.gif){kind=small}
bitoniau увидел довольно распространенное мнение — мол, известная демоплата Arduino не нужна, можно собрать то же самое «ручками», то есть съездить в «Чип-и-Дейл», купить паяльник ватт на двести, припой — лучше всего ПОС-40, флюс — канифольку смрадную, текстолит гетинакс, хлорное железо, микроконтролер, горсточку бракованных деталей, набор тупых мелких сверл, затем загадить мерзким раствором пол-квартиры, взять паяльник за «не тот» конец, собрать программатор, плату с микроконтролером, потом поставить на компьютере AVRStudio, WinAVR и еще кучу всякой дряни, сжечь LPT-порт при прошивке — и все это только для того, чтобы поморгать диодиком. Мало кто сейчас следует книжке Борисова и тренируется «на кошках», то есть на выпаянных неизвестно откуда КТ315. А зря, ибо когда Борисов начинает рассказывать о цифровых микросхемах (и на этом, кстати, книжка уже почти заканчивается), «юный радиолюбитель» превращается в закоренелого паялу, а для такого запаять 24-ногое чудо враждебной техники — раз плюнуть.
Казалось бы, чего общего может быть у умещающегося в одном DIP-корпусе микроконтролера и огромной IBM System/360, занимавшей несколько шкафов и жравшей немерянное количество электроэнергии, и какое отношение книга Брукса может иметь к «единоличной» разработке программ для МК? Дело не в том, что микроконтролер близок по своим «ресурсам» к «суперкомпьютерам» прошлых лет (System/360 всяко покруче будет!). Просто в те времена еще не было замечательных линуксов, работающих на кофеварках, и программы писались на сравнительно низком (не плохом, а приближенном к «железу») уровне. А особенно верно это для операционной системы совершенно новой машины — основываясь на опыте разработки которой, Брукс и написал книгу.
Вот один только абзац:
В наше время мы привыкли к тому, что аппаратная часть компьютера большую часть времени работает без сбоев. Если только разработчик прикладной программы не замечает, что система неодинаково себя ведет при разных идентичных прогонах программы, ему правильнее всего поискать ошибки в своем коде, а не в технике.
Этот опыт, однако, сослужил плохую службу при программировании новой машины. Лабораторные разработки, предварительные или ранние выпуски компьютеров не работают должным образом, не работают надежно и не остаются неизменными день ото дня. <…> И хуже всего неопределенность, лишающая стимула копаться в своем коде в поисках ошибки — ее может там вовсе не быть.
Программирование для микроконтроллерных систем — в чистом виде системное программирование для «новой машины». Да, микроконтроллер — довольно хорошо изученная и документированная штука, но вот трудность вызывает сборка «первой схемы», особенно, если это схема на МК. Разве может начинающий знать, что керамический конденсатор необходимо разместить как можно ближе к корпусу микросхемы? А то, что блокировочные конденсаторы для пары микросхем вовсе не стоит заменять одним, пусть даже и с емкостью, равной суммарной? А нюансы, связанные с подключением кварца?
Непонятно, почему «светодиодная моргалка», собранная «по всем правилам», не хочет работать. Дело ли в программе, в прошивальщике, в программаторе, в схеме, в монтаже — начинающему не понять. А применительно к AVR — вспомним хотя бы о «фузах», неправильной установкой которых так легко угробить контроллер (купленный, естественно, в единственном экземпляре).
Современный программист привык к тому, что железо всегда работает нормально, именно поэтому многие, спаявшие простейшую схему на МК, так никогда и не находят «соплю» между ножками. Демоплаты как раз и решают проблему с «нестабильностью» собранного новичком в «паяльном деле» «железа». Как минимум, повышается шанс запустить первую программу на нормально работающем «железе».
Касательно Arduino — лично я не вижу ничего особо выдающегося в этой плате. Разве что какой-то набор функций (своего рода «ОС») и Bootloader — вот и все, чем эта штуковина отличается от других плат. Ну и пиар, соответственно.
Для разговора про ардуиновскую «стандартную библиотеку» хочу вновь обратиться к истории. Технологии и методы программирования развивались в тесной связи с развитием возможностей «железа». Та же Simula оказалась невостребованной в конце 60-х — для тогдашних компьютеров более естественными оказались «процедурные» языки. Приведу маленький пример.
Для не очень хорошего программиста на Java или любом другом подобном языке вполне естественно написать что-то вроде:
var s = new String();
for(var i = 0; i < 100; i++) String += i + ",";
Кое-кто может сослаться на историю маляра Шлёмы, но речь немного не об этом, тем более что класс String можно реализовать и без недостатков сишных строк. Если кто-то, подобно тому не очень хорошему программисту, не читал книжек по Java или другим языкам со "сборкой мусора", то предлагаю проследить, что же происходит в цикле. При каждой его итерации создается несколько экземпляров класса String, которые не уничтожаются сразу после окончания вычисления (как в C++), а остаются в памяти.
То, что мы не заботимся о явном выделении памяти и ее освобождении, и называется абстракцией. Нас не волнуют такие вещи, как стек, страницы памяти и прочие малопонятные вещи. Даже мусор за нами должен собрать "сборщик мусора" (кстати, тоже сделанный в Simula).
Естественно, что за возможность написать код, наподобие приведенного выше, надо чем-то расплачиваться - а именно, ресурсами выполняющей эту гадость машины. Комфорт программиста, не заботящегося о "смысле", скрытом за легко читаемой строчкой, оплачивается памятью, тактами процессора и прочими ныне почти забытыми понятиями. Именно поэтому Simula и оказалась не нужна в 60-х. А вот разработанный практически в те же годы C оказался гораздо интереснее для компьютеров с очень сильно ограниченной памятью, да и на тех же AVR широко используется.
Похоже, то, что avr-gcc умеет компилировать и объектно-ориентированный C++, послужило поводом реализовать "объектно-ориентированную" стандартную библиотеку Arduino. Хоть Страуструп и утверждает, что "никакое языковое средство не должно приводить к снижению производительности программ, не использующих его", но из этого совершенно не следует, что реализованные с использованием ООП и без оного аналогичные функции будут работать одинаково.
Зато кому-то стало легче - не надо изучать такой непонятный RS-232, достаточно лишь написать Serial.println(15 - 10) :) А потом начинаются пляски с бубном около ООП-шных изысков, реализованных на неподходящей для этого системе.
PS Я ни в коем случае не утверждаю, что объектно-ориентированное програмирование, преобразование типов и прочие замечательные особенности соременных языков программирования - это "аццтой". Они действительно облегчают жизнь. Сборка мусора - это гораздо лучше, чем ручное управление памятью, примерно настолько же, насколько современная автоматическая коробка передач превосходит ручную. Только вот не надо пытаться присобачить "автомат" к "Жигулям" (за ссылку спасибо onfall).
