Борьба с оптимизатором, на мой взгляд от незнания/непонимания языка и от неправильного его применения. По поводу прозрачности - мне мои исходники нравятся
ну да, дефайны, условная компиляция, вычисления в препроцессоре, макросы и обильные комменты использую "в полный рост". Трудоёмкость написания программы... ну не знаю, обычная вроде, как-то на спор с приятелем писали болванку (main-цикл, инициализация таймера, мигание светодиодиком) для tiny2313, он на Си, я на АСМе, у меня получилось быстрее на пару минут

Хотя, конечно понимаю, что возьми мы за тест какую-нить математику с "плавучкой", я бы безнадёжно отстал. А проекты бывают всякие, например один из последник - 7К ассемблерного кода (гаджет для айфона) Моё мнение, что грамотное программирование на Си - отнюдь не тривиальная задача, и требует напряжения мозгов побольше, чем с ассемблером. по моему я уже как-то цитировал слова моего знакоого программиста (который работал в американской компании в области защиты софтаи писал драйвера, исключительно на АСМе). так он говаривал "я слишком тупой, чтобы писать на Си". И это довольно философские слова. Я считаю, что грамотных Си-программистов не очень много.
Ну а я вообще "не от мира сего". Мне например нравится всякая экзотика навроде ФОРТа

и ассемблера

И вообще, я пожалуй где-то перфекционист. Как говаривал У.Черчилль: "Я не слишком-то требователен - мне достаточно самого лучшего". Порой это мешает работать (например мешает впарить заказчику какую-нить "лажу"), но это уж извиняйте, моя жизненная позиция. Что-то как-то разговор от МК, плавно перешел к разговору "за жизнь". В общем пока не ощущаю острой необходимости в глубоком изучении Си
ну ну вот вам одна из задачек:
медицинский proximity датчик с логгером:
определение факта установки пациентом стоматологического ортопедического изделия и посчёт времени его ношения
этап выработки концепции ("что и как") опустим, приведу конечные требования для разработки
питание - Li CR1216 (ёмкость 30мА*ч)
диапазон измерения температур - 30-45 С
точность измерения +/-1 С
фотометрический датчик (видимый свет)
периодичность измерений 5 сек (точность ведения лога)
беспроводной интерфейс передачи данных
автономность - не менее полугода в режиме измерений
сохраняемость - не менее 5 лет
конструктив - герметичная капсула без каких либо контактов диаметром не более 14мм, толщиной не более 3мм
возможность активации капсулы (запуск работы)
себестоимость устройства (без учёта корпусирования и стоимости источника питания) - не более $1
Ну ка давайте ка сюда со своими кортексами и сями, а я посмеюсь, вместе с конкурентами
+Кортекс тут не нужен, а что Вы имеете против Си для этой задачи?
+банально не хватит ресурсов, ибо тут копеечный МК, с 0,5К флешем и 32 байтами ОЗУ (в частности - tiny5). Какие тут нахрен Си ?? -
+Писал на Си даже для ATtiny12, которая вообще без ОЗУ
+Это такой же экстремизм, как агрессивное неприятие Си
да, согласен, крайность это всегда ненормально (вот поэтому я и думаю насчёт АРМА + Си (пока не нахожу явных предпочтений Си над АСМом для моих задач, хоть и понимаю, что нужно избегать другой крайности - тащить асм туда, где Си может быть более уместен (да, и такое допускаю .
+вероятно, для Асм и Си есть разные ниши применения,+ для каждого разработчика своё кому-то и для tiny2313 уже Си подавай, а мне, так на всю линейку АВР асма вполне хватало, си и даром не надо. Вот с АРМами - действительно вопрос.
Пока думаю, но сознание активно сопротивляется против Си - прозрачность АСМ-кода, - опыт реализации довольно сложных проектов (полное использование ресурсов контроллеров класса mega/xmega ничуть не пугает) - наличие своих наработок и библиотек За Си - сложность АРМ периферии и нежелание детально вникать в новую архитектуру (на уровне регистров и бит) - действительно более лёкгое написание программ класса "говнокода" (но я прринципиально стараюсь не писать такого

При этом написание действительно красивой и правильной программы на Си - далеко не так просто, как кажется (ольшинству) на первый взгляд - наличие библиотек (отчасти перекликается с предыдущим пунктом) - условная переносимость пограмм (на уровне алгоритмов, не привязанных к особенностям "железа") но у меня как правило из-за особенностей задач, кк раз наоборот - очень жёсткая привязка алгоритмов в конкретному железу. -------------- думаю в общем, есть За и Против......