Я нашел еще один (очень простой) график, отражающий рейтинг языков программирования. Всё элементарно: по горизонтали — количество проектов на Github, по вертикали — количество вопросов на Stackoverflow.



Я позволил себе провести на этом графике две красные диагональные линии, чтобы показать как наглядно отделены друг от друга мейнстрим (C++, C#, Java, PHP, Javascript и т.д.), группа «альтернативного мировозрения» (Scala, Haskell, Erlang, Prolog, Lisp) и откровенный трэш (всё, что ниже). По-моему, проще некуда. Никаких там годовых колебаний в полтора процента, высчитанных по непонятным формулам.
Взято тут.

UPD: сорри за мини-троллинг со словом «трэш» — зато он породил весьма интересную дискуссию в комментариях. Всем высказавшимся — спасибо.

Февральский рейтинг языков программирования, публикуемый компанией Tiobe, показал следующее:

• Самыми популярными языками программирования остаются Java (первое место) и С, причем отрыв последнего от лидера весьма мал. Однако же, лидерство этой пары очевидно.
• Самым популярным языком программирования серверной части web-приложений остается PHP. Python и Perl отстают от него довольно значительно.
  
• JavaScript — топ-язык для клиентского web-программирования.
  
• Значительно выросла доля Objective-C (5-е место): вероятно, играет роль популярность продукции Apple.
  
• Доля объектно-ориентированных языков составляет около 50%, процедурных — 36%.
  

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

Недавно у меня возникла такая необходимость — использовать распознавание музыки в собственной программе. Программа разрабатывалась на C#, это сортировщик коллекции mp3 файлов, заточенный под себя. В двух словах скажу, что к примеру, он умеет распознавать по ID3 тэгам принадлежность произведения к классической музыке, и соответственно раскладывать по папкам на диске не /Исполнитель (год-год)/Альбом (год)/Произведение, а /Композитор/Альбом/Произведение.

Изначально, мне пришла в голову идея использовать для этой цели Winamp, так как он неплохо справляется с задачей распознавания ID тэгов по отпечатку аудио. Есть идея — есть реализация! В списке треков появилась кнопочка, которая создает в %TEMP% m3u список и запускает Winamp передавая ему m3u как параметр, а приложение отслеживает ChangeFileNotification и если тэги были обновлены в Winamp — автоматом обновляет информацию в своих окошках. Однако спустя некоторое время я понял, что это неудобно, непонтово и решил вживить в код такую же фичу, как в Winamp.

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

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

Когда-то, во времена Вседозволенности и Хаоса программы хранили настройки пользователей где-придётся. Многие держали одну копию настроек на всю систему. Со временем все ОС обзавелись нормальными профилями пользователей, начали ограничивать доступ к системным папкам и всех программистов стали с яслей учить хранить настройки пользователя в папке (ветке) его профиля. Казалось бы, на том и сказочке конце. Но нет. Есть случаи, когда этот подход не работает. Я продемонстрирую это на примере ошибки (именно архитектурной ошибки, а не банального бага в следствии опечатки) в одном из приложений Google.

У меня возникла такая задача: нужно обработать файл с данными. Файл разбит на секции длиной около 1 МБ, каждая из них содержит в упакованном виде примерно 100000 записей.Число записей может меняться от секции к секции и записано в заголовке каждой из них. В процессе обработки секция распаковывается, и каждая запись превращается в 20 целых чисел. Для обработки нужно хранить текущую распакованную секцию и несколько предыдущих (где-то 5-10, но может быть и больше – заранее неизвестно, сколько). Вопрос в том, как выделять память для распаковки секций.

Проект, в рамках которого надо решить задачу, пишется на C# под VS 2008 (использование вставок из других языков категорически не приветствуется), основная система, под которой будет работать готовая программа – Windows 7, 64 bit (по крайней мере, пока). И, как обычно, обрабатывать нужно побыстрее.
Первый вопрос, который возникает – надо ли организовывать пул массивов для распаковки, или можно захватывать массив для каждой новой секции заново. Второй вопрос – какой должна быть структура этого массива, что лучше – работать с линейными массивами в 8 МБ длиной, или разбить массив на куски поменьше и организовать, например, массив массивов. Во втором случае – какой должна быть длина этих кусков.

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

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

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

Мы все знаем, что в мире создано несколько тысяч языков программирования. Один только список программ Hello, world с сайта Wikibooks включает в себя 230 категорий (полный список на сегодня состоит из 402 элементов). При этом известный рейтинг TIOBE подтверждает очевидное соображение: основная масса этих языков скорее мертва, чем жива. Уже на долю первого десятка языков приходится 76,77% всех учтённых TIOBE проектов. Второй десяток увеличивает эту долю до 85,61%. Стало быть, на оставшиеся 30 языков (TIOBE учитывает лишь первые 50 языков при расчёте процентов) приходится менее 15% упоминаний.

Понятно, что рейтинги заключают в себе некоторую долю лукавства, поскольку даже непопулярный по общим цифрам язык может быть крайне важен для какой-либо узкой сферы. Возьмём любимый здесь многими Erlang или Haskell (39-е и 41-е места рейтинга) или ещё более очевидные Simulink и LabVIEW, вообще не попавшие в Top 50, но незаменимые в своих областях. С другой стороны, очевидно, что языки действительно приходят и уходят, и популярность, скажем, Паскаля обречена на снижение, поскольку на смену идут более прогрессивные языки, метящие в ту же нишу. (Не будем упоминать здесь Delphi, в котором от Паскаля остался разве что базовый синтаксис. У традиционного паскалиста листинг на Delphi может вызывать такой же ступор, какой у меня вызвала первая увиденная мною программа на Visual Basic 6, с этими Private и Public, Option Strict и Dim As, напрочь отсутствовавшими в родном Бейсике ZX Spectrum.)

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