Есть такая фраза, являющаяся непреложной истиной для каждого сторонника диалектического материализма — «Бытие определяет сознание». Естественно, всякие идеалисты используют противоположные вариант — «Сознание определяет бытие», после чего жестоко ругаются с материалистами.
А вот в разработке ПО, видимо, можно сформулировать аналогичную вещь: «Возможности железа определяют методику разработки ПО». Я об этом писал на примере Arduino, а вот еще пример, не менее поучительный. Недавно видел у ![[info]](http://stat.livejournal.com/img/userinfo.gif){kind=small}
belnetmon ссылку на статью о разработке ПО для мобильной операционки Android. Что же нам в ней советуют?
Ресурсы нужно экономить.
Нужно мгновенно выдавать реакцию на действия и поддерживать обратную связь с пользователем.
Производительность приложения главная цель. Нужно постоянно в процессе разработки оптимизировать производительность, не оставляя эту работу на потом.
Нужно измерять время выполнения, протоколировать и анализировать ход выполнения приложения, узкие участки кода, возникновения событий, выделение памяти, время жизни объектов. Что не измеряется, то нельзя оптимизировать.
Избегайте создания лишних объектов.
По возможности делайте методы статичными.
Используйте прямой доступ к полям вместо методов посредников.
Используйте static final для констант.
Не используйте enum там, где достаточно обычной переменной целого типа.
Все это вытекает из возможностей «железа». Современные мобильники и КПК сравнимы по производительности с «персоналками» где-то десятилетней давности (причем очень «грубо» — например, над 24 доступными для процесса мегабайтами ОЗУ в 2000-м году посмеялись бы). Вспомним, что происходило в программировании в те далекие времена.
Бывшие паскалисты (спасибо дядьке Фаронову!) успешно освоили «программирование мышкой» в Delphi. Сишники разделились на два лагеря — первые вслед за паскалистами поклялись в вечной любви к фирме Borland и пользовались CBuilder, вторые забыли TurboC, как страшный сон, и переметнулись в стан любителей Microsoft Visual Studio 6.0. С++ использовался в варианте «C on steroids» — слова «инкапсуляция», «наследование» и «полиморфизм» до многих доходили слабо, зато «заклинания» типа TForm1.OnClick() весьма понравились. Надо ли говорить, что полноценного стандарта C++ не было реализовано нигде, библиотека STL зачастую отличалась непредсказуемым поведением (например, в книжке Б. Кернигана и Р. Пайка «Практика программирования», вышедшей в 1998 году, приводится пример, когда один из Windows-компиляторов С++ был снабжен ужасно медленной версией входящего в STL дека), да и поведение компиляторов иногда оставляло желать лучшего (кто помнит, почему не стоит писать «for(int i=0; i < N; i++)" в VC++ 6.0?). Языки программирования, отличные от C и Pascal, в нашем Отечестве не котировались (по причине неведомо кем культивируемой веры в крутость русских программистов), а в Буржундии к тому времени уже по достоинству оценили хоть и более медленные, зато более "безопасные" Java и Visual Basic. Кстати, там же, в Буржундии, как раз к 2000-му году вылезли из своих нор мамонты и динозавры - знатоки FORTRAN, поправили где надо год и отправились на заслуженный отдых, пока им в аду прогулы считают. Замечу, что "интерпретируемые" языки, с "безопасными" типами, где программисту полностью закрыт доступ к опасным возможностям, появились лишь по той причине, что буржуины всегда умели считать деньги и прекрасно понимали, что дешевле нанять десяток индусов, чем двух сишников - больше шансов получить на выходе программу, не заваливающую систему два раза в час, да и следствие из закона Мура - если ваша программа тормозит, отложите выпуск - уже было взято на вооружение. С другой стороны, "Практика программирования" Кернигана и Пайка тоже написана не на пустом месте и не потеряла актуальность в начале 2000-х (а то и сейчас, во всяком случае, многие похапешники после нее будут плакать кровавыми слезами). Несмотря на все замечательные возможности языков, очень большое внимание уделялось и производительности - часто даже в ущерб языковым возможностям (например, самописный hashmap часто оказывался существенно быстрее STL-ного, в результате чего мог считаться предпочтительнее). В общем, советы по программированию для Android лишний раз напоминают, что удобные возможности языка и среды выполнения зачастую сильно влияют на производительность программы - причем зачастую отрицательно. PS А вот более развернуто мое мнение про Arduino: http://community.livejournal.com/ru_radio_electr/759218.html?thread=12768946