Давайте сравним. Поиск алгоритма быстрого преобразования Фурье (FFT) у меня дал такие результаты: Koders.com – 23.5 тыс. результатов, а Google code – «примерно 3 результата» (я так и не понял, почему «примерно»).

Удачного вам поиска по исходникам!

А вы знаете самый суровый прокол всех времён и народов, связанный с техническим заданием?

Наверное самый-самый-самый острый косяк был у американцев, когда они запускали Аполлон-13. Подумать только! Из-за промашки в ТЗ:

• не сели на Луну;
• угробили модуль стоимостью миллионы долларов;
• чуть не угробили троих мужиков!!!

И всё из-за неправильной постановки задачи. Неверно вписали одну единственную цифру, а потом не перепроверили (помните, в документации есть графы «Утвердил», «Проверил»… ).

Надеюсь, для многих читателей Берлоги инженера не стоит вопрос как написать техническое задание?

Собственно, к теме меня подтолкнула статья моего молодого (почти) коллеги Криса Касперски. Языки, которые мы потеряли. Давненько я задумываюсь о языках программирования. И периодически «вопросы познания» этих языков всплывают у меня с прочтением подобных статей.

Ровно три года назад я написал небольшую статью на эту тему: Рейтинг языков программирования. Теория и практика, где формально, с помощью цифр, тестов, рейтингов и статистики отмечал, что практикующие специалисты-программисты используют в массе своей далеко не самые эффективные языки!

Вот и в приведённой статье Криса отмечается то же самое. Только немного в плоскости анализа семантики языков. Приведу ряд полезных цитат.

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

Самолеты и космические корабли мирно сосуществуют с велосипедами и автомобилями. Никому ведь и в голову не придет летать за сигаретами на ракете, особенно если сигареты продаются в киоске на соседнем углу.

Но ведь это же неправильно! Появление ракет должно перевернуть наше мышление! Поэтому — строим киоск за орбитой Плутона и каждому даем по ракете, чтобы туда летать, а горючее покупаем за деньги, вырученные от строительства космодромов и продаж ракет. Кто не может строить ракеты — пусть учит других, как на них летать. Сколько создается новых рабочих мест и главное, что все в бизнесе. Вот тут уж действительно, возврата в прошлое нет… Сигареты стоят миллиарды долларов, и деньги в индустрию вращаются просто огромные. Кто же захочет от них отказываться?! Напротив, ракеты будут стремительно «совершенствоваться», чтобы за сигаретами можно было летать даже на Альфу Центавра.

Говорите, что это нелогично и невозможно? Но ведь именно такая ситуация сложилась с Си++. Судите сами — реализация компиляторов языка Си++ очень сложная и дорогостоящая задача, а сам язык настолько обширен и объемен, что его изучение требует невероятных усилий. Чтобы окупить средства, вложенные в разработку компиляторов, фирмы вынуждены «подсаживать» на него миллионы программистов, которые, пройдя длительный (и ужасно мучительный) путь обучения Си++, просто не могут признаться себе в том, что напрасно убили десять лет своей жизни (данной человеку лишь однажды!) и что стоящие перед ними задачи с ничуть не меньшей эффективностью реализуются на чистом Си и других процедурных языках, легко осваиваемых на ходу без отрыва от производства. Вот они и начинают убеждать остальных, что процедурные языки давно мертвы. Сложность ради сложности.

Как-то так получилось, что в работе своей я частенько сталкиваюсь с различными языками/диалектами. Когда-то пытался посчитать. Насчитал более десятка. И вроде бы для каждого конкретного случая (например, программирование ПЛИС или контроллера) можно подобрать C/Cpp-подобный язык, я всё равно программировал на языке, более близком к конкретной платформе или задаче. Пытался применять C/C++! Но ничего путёвого это не приносило. Всё равно наработки сложно переносить из проекта в проект (да и бессмысленно порой, такая у меня специфика), а эффективность С/C++ на некоторых платформах бывает «ниже плинтуса» по объёму кода, по скорости, и даже по эффективности/скорости разработки!

Нет, я не сбрасываю со щитов достоинств современных популярнейших компиляторов и систем/подходов к программированию! Они себя оправдывают, вполне оправдывают. Но получается так, что по сути оправдывают больше не себя и не процесс разработки и творчества, а рыночную ситуацию. Как сказал Крис, «Сложность ради сложности». Жаль, но по сути так и получается.

Появляются новые платформы, усложняются процессоры (становятся многоядерными). И появляются новые клоны «популярного» С++ с новыми «граблями», «заплатками» и прочей требухой, позволяющей хоть как-то обеспечить требуемую функциональность.

«Узкие» профессионалы в своих областях продолжают работать на более эффективных паскале-, ассемблеро-, лиспоподобных языках, а армия «поклонников» упорно трудится над сборкой компиляторов и кросскомпиляторов, чтобы оправдать «убитые годы жизни».

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

И, к сожалению, новое чаще появляется не путём модификации старого, а путём приписывания/дописывания:

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

Появление более эффективного «железа», на мой взгляд, осложняется именно сложившейся ситуацией с языками программирования. Ведь ещё лет десять назад производители микроконтроллеров говорили о «С-совместимости ядер». Оно неплохо. Но это не позволяет сделать революцию, принципиальный скачок вперёд!

Задумайтесь к примеру, если забыть о всех «граблях» С++ и даже С, то легко ли будет на этих языках реализовать параллельные вычисления на каком-нибудь 4-ядерном «пне» последней конструкции? Вот сесть и накидать программку за часик, которая честно использовала бы ресурсы всех четырёх ядер? Нет, не получится. И мы это перекладываем не на программиста (кому как не ему знать о том, как более эффективно раскидать-распараллелить задачу!), а на ОС. Вот и получается, «как придётся»… Вот мы и покупаем более дорогие и производительные компьютеры, а работа более эффективной не становится…

Хочу задать вам, уважаемые читатели, вопрос. Как же и куда же нам двигаться в такой ситуации?
Продолжать изучать «популярные языки»?
Придумывать что-то своё?
Изучать узкую область и быть в ней ассом, но профаном в других областях?

В раздумьях и размышлениях вам могут помочь:
Рейтинг языков программирования
Эффективность языков программирования
Перлы программирования и алгоритмизации

И ведь не подкопаешься! Комменты пишутся живыми людьми, руками, иногда они даже вполне осмысленные – антиспам-фильтры их в упор не видят. Настораживают только адреса сайтов – то это про отдых в Египте, то про стальной прокат – ну мало ли о чём люди на досуге пишут.

Отключить комментирование нам даже в голову не приходило, ибо каждый инженер знает, что система без обратной связи становится неустойчивой и, как следствие, нежизнеспособной.

Что-то надо было делать, и тут мы вспомнили про наш плагин для WordPress. Вооружившись ломом и напильником, мы расширили его функционал, и теперь комментарии в админке выглядят следующим образом:

Плагин можно скачать здесь. Установка его подробно описана в нашей статье, однако если вы до этого пользовались старой версией, плагин при установке необходимо деактивировать и затем активировать вновь, иначе функция отображения User agent работать не будет. Следует также отметить, что плагин работает совместно с плагином Subscribe To Comments. Что будет, если последний не установлен, мы не проверяли. В дальнейшем мы сделаем отдельную страничку по плагину, где будет самая актуальная информация по его установке и использованию.

Что же мы получаем при помощи Comment extender? Итак, как вы уже заметили, количество информации о комментаторе увеличилось. Теперь мы можем отследить, каким браузером под какой ОС он пользуется, а также прикинуть, как часто он оставляет свои комментарии. Также можно посмотреть комментарии с одинаковыми параметрами (для этого нужно кликнуть на соответствующие цифры).

Наш небольшой опыт использования плагина показал, что один из самых полезных параметров – это IP. Нам удалось обезвредить несколько спамных комментов, отличавшихся по URL и email, но имевших одинаковый IP и довольно невнятное содержание. Кроме того, весьма полезен параметр, показывающий наличие/отсутствие подписки на комментарии. У нас на блоге в форме отправки комментария галочка «подписаться» стоит по умолчанию. Редко какой обычный пользователь снимает её. Это если смотреть через браузер. При использовании всяких хитрых программ, когда сразу отсылается запрос, наличие этой галочки совершенно не учитывается, что может служить ещё одним косвенным признаком спама.

Что же делать с обнаруженными комментариями? Мы рекомендуем не удалять их, а помечать как спам. При этом они будут оставаться в базе, что позволит статистике нормально работать (в противном случае у вас потеряется вся информация о предыдущих похождениях спамера), а также обучит ваш антиспам-фильтр, что явно убавит у вас работы.

Если функциональность Comment extenderа вас не устраивает – пишите нам, всё в наших руках, добавим, поправим. Если плагин понравился, поспособствуйте его распространению. Наша задача – сделать труд спамера нерентабельным, и в нашем случае сделать это вполне реально. Сделаем мир чуточку лучше!

Что легче — создать компьютер или написать для него программу? С ростом потребностей второе становится всё труднее и труднее. Тенденции таковы, что чаще «железо» делают так, чтобы сохранить преемственность от старых моделей. Посудите сами: на всех современных процессорах могут работать программы для Intel 80386 (если не раньше). Прогресс даже в какой-то степени сдерживается тем, что трудно написать операционную систему и программы для нового компьютера/процессора — легче взять то, что было и постепенно наращивать потенциал. Так появились новые наборы команд, так двигались в развитии видеоадаптеры и прочая периферия.

Но какое отношение всё сказанное имеет к виртуальным машинам? Самое непосредственное. У многих исследователей и разработчиков появилась мысль создать ПО, которое бы работало на любых компьютерах с процессорами самых разных архитектур. Это решило бы не только вопросы переносимости, но и проблемы преемственности, оторвало бы программу от аппаратной платформы. А что для этого нужно? Правильно! Нужна прослойка между «железом» и ПО, которая, внося свой уровень абстракции, делает недоступными аппаратные ресурсы напрямую, но зато облегчает и упрощает доступ к ним.

Эту идею классически реализовала Sun в своей Java Virtual Machine (JVM — часть любой системы Java Runtime Environment (JRE). Смотрите, например в Java ME). Виртуальная машина исполняет не машкоды — она интерпретирует байт-код. Байткод не зависит от платформы. Он компактен и быстрее интерпретируется, чем программа «в исходниках».

Получается так, что Sun создала свою виртуальную среду в которой машкод — это байт-код. Эта среда более гибкая и универсальная, чем «железный» процессор. Эту среду можно эмулировать. И появление Java как раз пришлось на 90 годы двадцатого столетия, время, когда появились мощные процессоры, способные справиться с задачей эмуляции.

Сейчас на большинстве современных мобильных платформ установлена Java ME, включающая JVM. Любой мало-мальски продвинутый телефон способен запускать Java-игры. Многие серьёзные программы и среды проектирования пишутся на Java, чтобы обеспечить кроссплатформенность, а значит расширить область применения ПО. Пример тому — программа GanttProject из нашей коллекции бесплатных программ, раздел Офис. Это Java-программа. Она работает где угодно, — там, где можно установить соответсвующую ей Java VM.

Лавры победителей никогда не давали спокойно спать корпорации Microsoft. И если Sun разрабатывала Java с начала 90-х, а в середине 90-х выпустила в большой свет, то уже в 2000 году Microsoft дала свой ответ – .NET. Но и свободное сообщество тоже не дремлет. Родился проект Mono. Этот проект призван реализовать .NET на базе свободного ПО. Спонсор проекта – Novell.

Эмуляторы, позволяющие запускать компьютерные программы операционных системах, отличных от той, для которой они создавались, развиваются постоянно. Но самое широкое распространение они получили в среде Linux. Это закономерно: можно потратить силы на написание одного эмулятора, а потом пользоваться множеством программ Windows. Cedega, Wine, CrossOver – хорошо известные многим названия. Эти эмуляторы дают возможность расширить применяемость ПО в различных операционных системах.

Но людям хочется работать не только в иной операционной системе, но ещё и на другом компьютере, «компьютере в окне», отличном от том, на котором работают. Это позволят сделать виртуальные машины, напрмер Bochs, Parallels, QEMU, VMware. В «окошке» виртуальной машины можно установить любую ОС, а в ней уже запустить любую программу. В этом случае стираются границы не только на уровне операционных систем, но и на уровне аппаратных платформ. И если писать и отлаживать программу для Windows в Linux мягко говоря глупо и бессмысленно, то отлаживать драйвера для различных аппаратных систем не вставая со стула – вещь весьма полезная.

А теперь немного «крамолы» с точки зрения программистов.

Хочу продолжить тему виртуальных машин. «В железе». Я бы выделил семейство ARM как семейство ядер, подпадающих под вышеприведённую классификацию. По сути, ARM – универсальное ядро, универсальная виртуальная машина, которую используют многие производители для создания своих процессоров. Улавливаете смысл? Есть ядра x86, DSP, микроконтроллеров. Но все они привязаны к конкретной архитектуре, к конкретному набору периферии. Компания ARM же сделала великое дело – унифицировала ядро, создала «виртуальную машину в железе».

Это позволило запускать одни и те же программы на процессорах от различных производителей: Intel, Atmel, Cirrus Logic, NXP (Philips), Texas Instruments… На процессорах с разной периферией, с абсолютно разными порою аппаратными особенностями.

Разработчики и программисты в последнее время достигли просто вершин виртуализации. На «виртуальном» ядре ARM работает виртуальная машина Java. В помощь ей развивают технологии Jazelle, позволяющие ускорять Java на ARM.

Итак, мы увидели, что с развитием аппаратных возможностей расширились возможности создания виртуальных машин и эмуляторов. «Виртуалы» служат хорошую службу. Они расширяют возможности человека, связанные с примняемостью программного обеспечения на разных платформах, и наоборот, с применяемостью различных программ и ОС на одной платформе.

Можно выделить целый ряд «полезностей» применения виртуальных машин:

• Виртуальные машины позволяют быстро (не прибегая к реальной аппаратуре) менять конфигурацию аппаратных средств и выполнять на ней требуемый код. Я бы назвал это универсальностью и многовариантностью.
• Вы можете на одном реальном компьютере запустить сразу несколько ОС в различных виртуальных пространствах. Эти ОС не будут (иногда) даже знать о том, что работают не на «железе», а в программе, которая этот процессор и всё его окружающее «железо» эмулирует. Таким образом, виртуальная машина обеспечивает независимость и изолированность.
• Зависла программа, «упала» ОС, работающая в одном из виртуальных пространств — не беда. Другие-то продолжают работать! В целом ряде случаев виртуальная машина обеспечивает устойчивость.
• Виртуальная машина бывает гораздо дешевле реальной. Вы можете разрабатывать какую-то аппаратно-программную платформу. И пока создаётся аппаратная честь, можно уже начать писать программы, запускать ОС в эмуляторе, оценивать производительность, пытаться даже подбирать конфигурацию. Таким образом, виртуальные машины повышают рентабельность процесса разработки, увеличивают его скорость.
• Даже загрузка программы или ОС в эмулятор чаще происходит быстрее, чем в реальное «железо», что очень удобно при написании ПО, при отладке. Кстати, о последнем. Некоторые виртуальные средства позволяют отлаживать код, тогда как отладка на реальных системах иногда невозможна или может потребовать дополнений в схему (JTAG, например), что удорожит разработку и будет совершенно не нужно в серийном образце, и/или приобретения отладочного ПО и оборудования. Таким образом, виртуальная машина увеличивает эффективность разработки.

Чтобы получше разобраться в типах виртуальных машин, советую прочесть статью Тима Джонса Виртуальный Linux. Тим Джонс разделяет виртуальные машины на несколько классов. Выделю три из них:

1. С эмуляцией оборудования. Это когда эмулятор выполняет код как интерпретатор. Это самая медленная эмуляция. Но она имеет одно важное преимущество — выполнение кода любой платформы под любой платформой (как программной так и аппаратной). То есть вы можете эмулировать ARM под x86, или DOS на x86 под Windiws® CE на ARM, или uLinux на Blackfin под Windows® на x86 и так далее. Да, медленно, но зато таким и только таким образом (эмуляцией оборудования) можно эмулировать любую платформу на любой платформе (иногда совершенно концептуально различные).
2. Полная виртуализация. В этом случае на одной машине могут работать несколько ОС, работой которых управляет гипервизор. ОС совершенно «не чувствуют» присутствия на машине других ОС. Это достигается аппаратными средствами (современные процессоры x86 имеют в своём составе команды и средства, предназначенные для виртуализации; без них полная виртуализация была бы невозможной).
   Плюс полной виртуализации в том, что ОС работают быстро, так как (практически) не происходит интерпретации кода — код выполняется непосредственно процессором (практически) без модификации. Способом полной виртуализации можно запустить на машине любую (любые) ОС, которые поддерживают данную платформу. Но минус этой концепции в том, что невозможно таким образом (в принципе невозможно) запустить на машине эмуляцию аппаратной платформы, отличной от родительской (напрмер, запустить Windows® CE на ARM под x86).
3. Паравиртуализация. В этом случае гостевую ОС модифицируют под конкретный гипервизор. То есть гостевая ОС «знает», что виртуализирована и что на машине может работать ещё несколько таких ОС. Всё это делается для того, чтобы избежать модификации кода на лету, ускорить вызовы и переключения.
   Основным достоинством такой концепции является скорость работы гостевых ОС и приложений в них. Она максимальна. Гипервизор тратит на себя не так много ресурсов, как в случае с полной виртуализацией. Основной минус — потеря гибкости («незаточенную» гостевую ОС в такой системе уже не запустишь).

Вообще, разница между описанными классами виртуальных машин условна. Всегда есть свои «но». Каждая система виртуализации имеет свою концепцию в той или иной мере располагающую её на шкале от полной эмуляции оборудования до паравиртуализации. Также можно выделить и другие классификации, но приведённая выше мне лично кажется вполне удобной и соответствующей положению дел на сегодняшний момент.

Как пример можно привести известные виртуальные машины и эмуляторы, перечисленные в Сравнении виртуальных машин. Обратите внимание на то, что есть и русский вариант этой статьи, но он пока менее информативен. В колонке «Принцип действия» нет «чистых записей» «эмуляция оборудования» или «паравиртуализация». Всё с какими-то оговорками… В этом и есть прелесть всей картины — каждый её элемент чем-то отличается от остальных и имеет свои преимущества.

В заключение приведу несколько ссылок на интересные ресурсы/продукты.

Виртуализация при помощи coLinux. По сути coLinux — способ запускать приложения Linux под Windows. coLinux — порт ядра Linux, делающий его одновременно паравиртуализированной системой и гипервизором, который отправляет запросы не оборудованию, а родительской системе — Windows®.

Cisco 7200 Simulator. Это эмулятор Циско на ПК. Позволяет, фактически, превратить ваш компьютер в маршрутизатор известного производителя. Однако для работы нужны загрузочные образы Cisco IOS. Также поддерживаются «Cisco 3600 series (3620, 3640 and 3660), 3700 series (3725, 3745) and 2600 series (2610 to 2650XM, 2691)». Здесь ветка форума, посвящённая этому эмулятору.

Кое-что можно почерпнуть (или поделиться своими впечатлениями и переживаниями) на Нашем форуме. В его отдельной ветке Эмуляторы, симуляторы и прочее…