Статьи по Assembler


Обсуждение статьи "Зачем он нужен, этот ассемблер?" - часть 3


И если абстрагироваться от оптимистических оценок, и опираться только на сухие результаты этого единственного эксперимента, то мы вынуждены повторить неутешительный вывод, уже сделанный в оригинале статьи. Нет никаких причин разрабатывать приложения для Windows на ассемблере, за исключением одной-единственной: личного предпочтения разработчика.

 

Другое дело, следует ли считать эту причину существенной. По нашему мнению - да, стоит. Потому что мы глубоко убеждены, что склонность к программированию на ассемблере - это не следствие образования или опыта работы, а в первую очередь следствие типа мышления данного конкретного индивидуума. И этот тезис мы повторяли и будем повторять на страницах сайта. Начиная с шуточного психологического теста и кончая этими вполне серьезными рассуждениями.

Современное программирование базируется на абстракции, причем чем дальше - тем больше. Это естественный путь, проложенный от табуляторов первых ламповых ЭВМ до той далекой точки за горизонтом, где машинные языки в конечном итоге сольются с высшим проявлением абстракции - нормальным человеческим языком.

К сожалению, дар абстракции дан людям не в равной степени. Наверное, в этом проявляется рудиментарное наследие каменного века, когда одни индивидуумы абстрактно загоняли мамонтов в ловчие ямы, а другие вполне конкретно мочили несчастных сверху булыжниками и дубинами. В результате у первых больше развилось интуитивное правое полушарие головного мозга, а у вторых - рациональное левое. И теперь, по причине отсутствия мамонтов, первые занялись программированием на C++, а вторые - на ассемблере.

 

Еще раз сформулируем нашу позицию касательно размера приложения, выработанную в результате эксперимента с MyCall и на основании собственного опыта разработки приложений для Windows:

  • Разработка небольших приложений на ассемблере не дает ощутимых преимуществ по объему кода по сравнению с C++, а вернее, C, потому что в таких приложениях объектно-ориентированные возможности C++ обычно неприменимы. Пример тому - MyCall.
  • Что касается больших приложений, то однозначно выявить преимущество ассемблера перед C++ по объему кода практически не представляется возможным. В таких приложениях существенную роль играют диктуемые языком принципы организации программ. Ассемблер предлагает программисту хаотический стиль, и приходится применять усилия и специальные приемы (см., например, статью Лептонный стиль программирования) для преодоления этого недостатка языка. C++, напротив, стимулирует формирование у программиста объектно-ориентированного стиля, и лишь неспособность или нежелание воспринять его приводит к отказу от этого стиля в пользу хаотического. А по-разному организованные программы становятся практически несравнимыми, даже если решают одну и ту же задачу.
  • Еще более неочевидным становится гипотетическое преимущество ассемблера в объеме кода, если вспомнить, что приложения для Windows далеко не полностью состоят собственно из кода. Более того, в массе случаев код занимает в них меньшую часть. А гораздо больший объем занимают разнообразные данные: ресурсы, структуры, таблицы и прочее, прочее, прочее. Понятно, что данные в своем большинстве инвариантны к языку, и, следовательно, их наличие маскирует преимущество ассемблера в компактности кода.
  • Плюс к сказанному: современные компиляторы C++ (в частности, Visual C++), при установленном флажке "Оптимизация по объему" дают практически оптимальный код, лишь в малой степени уступающий коду, написанному вручную на ассемблере. Более того, простая небрежность, лень или неполное знание ассемблерщика способны легко разрушить его призрачное преимущество. А вот глупому компилятору C++ такие человеческие слабости незнакомы - он оптимизирует код всегда.




- Начало -  - Назад -  - Вперед -



Книжный магазин