typedef

Хе-хе, это не я, это все Петцольд сказал. Уж кому, как не ему, это знать!

А если честно, я с ним согласен. И сам все больше и больше отхожу от IDE в пользу Emacs, причем без средств управления проектами (да, я иногда меняю свое мнение). Во-первых, я нахожу, что «управление проектом» в техническом смысле — штука несколько эфемерная, и, во-вторых, в Emacs оно сделано ужасно неудобно.

В результате я решил, что хороший текстовый редактор повышает мою производительность гораздо сильнее, чем хорошая IDE. А автоматизация сборки и тестирования вполне удовлетворяется Autotools или cmake (статьи про которые я все никак не допишу), а что не смогут они, смогут сценарии bash или Power Shell.

P.S. Ссылку на Петцольда стащил у Сергея Зефирова.

(Еще не оценили)

 Loading ...

Я не зря написал «open source» с маленькой буквы, потому что сегодня в фокусе моего внимания не одноименное сообщество, а сама тенденция роста количества софта, который раздают бесплатно и/или с открытыми исходниками. Скажу даже больше: я против не только открытого софта, а вообще бесплатного.

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

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

1. Программисты таки создавали добавочную стоимость, но эта стоимость относилась к железу, так как компьютеры продавались вместе с набором программ. Чем лучше программы для компьютера, тем дороже его можно продать. Ну, а поскольку стандартной архитектуры не было, то открытие исходников не имело негативных последствий: все, кто мог ими воспользоваться, сначала должны были купить компьютер, с которым этот софт и так шел в комплекте.
2. В то время каждый пользователь был программистом, поэтому открытый софт был просто частью натурального обмена. Сегодня я отдал свою программу Васе, а завтра он отдаст мне свою.

Но жизнь-то — штука изменчивая, и вот, подвинув бородатых хакеров, за терминалы уселись банковские служащие и бухгалтеры. Потом все нарастающая стандартизация аппаратуры, платформенная независимость языков программирования, и вдруг — хоп! Программисты остались в меньшинстве, железо стало дешевым, а одну и ту же программу можно, хвала Юниксам, если не запустить, то уж собрать почти на любой платформе. Собственно, исчезли основные предпосылки существования опенсорса, имевшие место в 60-е и 70-е.

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

1. Интерес. Людям просто нравится творить. Но так как большинство программистов — не бизнесмены, и не способны продать свои творения, они их просто раздают. Впрочем, есть и идейные, которые раздают из принципиальных соображений.
2. Известность. Open source очень демократичен. Напиши хорошую программу, которой будут пользоваться миллионы, — и интерес к тебе со стороны работодателей сразу повысится. Собственные разработки с открытыми исходниками служат отличной заменой традиционным резюме: просмотрев исходники программы и историю ее разработки, можно гораздо больше узнать о разработчике, чем в ходе получасового собеседования.
3. Работодатель за это платит.

Если с первыми двумя пунктами все понятно, то третий не очень прозрачен. Приведенный ранее механизм с повышением стоимости железа за счет софта уже не работает. Тогда откуда же прибыль, чтобы платить программистам? Есть несколько вариантов:

1. Код с открытыми исходниками не является самодостаточной программой, а представляет собой некую библиотеку или фреймворк, являющиеся побочным продуктом при разработке чего-то большего. Исходники открываются, как правило, из рекламных соображений. Прибыль косвенная.
2. Компания активно использует свой же продукт с открытыми исходниками в своих разработках. Очевидно, что основная прибыль получается другими путями, а открытие исходников — просто жест доброй воли или, опять-таки, реклама. Прибыль снова косвенная.
3. Мифическая «техподдержка», о которой будет твердить не слишком подкованный апологет open source, объясняя, откуда у опенсорсников деньги берутся. Этот путь получения дохода имеет смысл разве что для крупных компаний вроде Rad Hat или Microsoft, которые могут поставлять настолько большие и сложные продукты, что для них может потребоваться обучение специалистов и поддержка (платные, разумеется).
4. Open source, вообще говоря, ничуть не противоречит коммерческому софту. Поэтому можно путем хитрого лицензирования требовать с клиентов денег, если продукт с открытыми исходниками используется в коммерческих разработках (вспомним Qt как хрестоматийный пример).
5. Научные гранты.
6. Всякие маргинальные способы вроде пожертвований или встраивания рекламы в пользовательский интерфейс (фуу).

То есть, прибыль получить можно, если хорошо постараться. А открытие исходников дает, во-первых, армию бесплатных энтузиастов-тестеров, а во-вторых, на пустом месте возникает лишнее конкурентное преимущество: при прочих равных условиях софт с открытыми исходниками (не говоря уж о бесплатном) предпочтительнее, просто потому что. Наверняка 99% пользователей в исходники не полезут, зато их будет греть мысль, что такая возможность у них есть.

Программистов, которые могут себе позволить и хотят заниматься разработкой открытого софта, подавляющее меньшинство. Качественный открытый софт убивает конкуренцию (и, в некотором смысле, прогресс) среди закрытого коммерческого софта. То есть, если разработана некоторая открытая программа, то вероятность появления успешной аналогичной (или даже чуть более функциональной) закрытой коммерческой программы исчезающе мала (пример — браузеры). Да и открытой, в общем-то, тоже. Выходит, что open source замедляет прогресс!

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

1. Я написал научную статью и выложил ее в открытый доступ. Это ускоряет развитие науки, так как другие ученые могут опираться на мои результаты.
2. Я написал библиотеку нечеткой логики и открыл ее исходники. Это ускоряет прогресс программирования, так как остальные разработчики могут сэкономить свое время, если им понадобятся такие функции. Если им нужно внести какие-то изменения, они берут и вносят. Здесь важно, чтобы лицензия открытого кода позволяла любое его использование, в том числе коммерческое.
3. Я написал редактор UML-диаграмм и раздаю его бесплатно. Это помогает другим разработчикам в их работе. Конечно, это убивает конкуренцию среди платных редакторов UML, но в целом служит прогрессу программирования.
4. У меня бессонница, поэтому я год ночами писал программу управления личными финансами, а так как мне лень заниматься продажами, то я раздаю эту программу бесплатно. Если программа удобная, то платные уже покупать никто не будет, даже если они немножко лучше. Конкуренцию теперь может составить только более функциональная бесплатная программа.

Итак, моя позиция по поводу всего вышеобозначенного:

• информация должна быть открытой;
• средства разработки и научные инструменты должны быть бесплатны и, возможно, открыты;
• остальные программы не должны быть бесплатными (но могут быть открытыми);
• тем не менее, если уже есть хороший открытый/бесплатный софт, то глупо было бы им не пользоваться.

(1 голосов, средний: 5.00 из 5)

 Loading ...

Везде есть свои плюхи и минухи. Ну вот, например.

С точки зрения пользователя:

• Windows неэффективен и негибок (хотя многие об этом не подозревают);
• Linux сложен в настройке и нестабилен (хотя многие это отрицают).

С точки зрения разработчика:

• Windows сложен в изучении и неизящен; тысячи функций, не объединенных стройной идеологией; закрытые исходники не позволяют понять, как оно внутри работает;
• Linux слишком разнообразен и многолик; для написания реального софта приходится пользоваться множеством библиотек с невнятной документацией и не всегда корректной реализацией; да еще и вечная проблема совместимости дистрибутивов.

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

Вот что нужно принимать во внимание при выборе:

• сложность установки, совместимость с железом;
• сложность настройки;
• наличие доступной информации по настройке и использованию ОС;
• выбор нужного вам прикладного софта, его качество и цена;
• стабильность и надежность;
• ваша продуктивность при работе с ОС;
• удовольствие от работы;
• мощность, простота и стоимость средств разработки;
• цена самой ОС и ее поддержки;
• тенденции развития;
• ценность знания этой ОС на рынке труда;
• и так далее.

Только это имеет значение, а не мнения других людей. Но некоторые вышеобозначенные критерии для разных людей сработают в разные стороны. Если, скажем, цена ОС является объективным показателем, то удовольствие от работы или даже сложность настройки — вещи субъективные. Кому-то нравится тыкать мышкой по кнопочкам, а кто-то ловит нереальный кайф от редактирования текстовых конфигов в черной, как наша жизнь, консоли. А кому-то просто нравятся надкушенные яблоки.

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

Например, я считаю неправильным курс Linux на доступность для «домохозяек». У него была своя замечательная ниша: ОС для бородатых гиков, да и еще неплохо подходил для серверных приложений. Были толпы высококвалифицированных фанатов. Теперь же эти толпы фанатов решили навязать свое мнение всему миру. В результате ядро распухло и мешает при ходьбе. Реинкарнация DLL Hell. Квалификация фанатов упала. Появилась куча клонов Windows-приложений, которые работают чуть-чуть не так, как надо. Зато опенсорс, да.

С Windows тоже беда, но обратная. Microsoft случайно сделал идеальную ОС для обычных пользователей: Windows XP. Дальнейшие дерганья только подтверждают неизбежное: все уже написано. Пользователи хотят чего-то нового, но новое от Microsoft подозрительно напоминает старое. Чем успешно пользуется Apple, который принципиально ничего нового не делает, но зато делает не так, как Microsoft, чем и привлекает уставших от пятнадцати лет унылого интерфейса пользователей. Зато уж средства разработки Microsoft как блины печет: уже вон .NET 4 выходит. Несчастные разработчики в мыле корпят днями и ночами над книгами и мануалами, чтобы потом, прочитав последнюю страницу, обнаружить, что за это время вышло еще два фреймворка и три языка, и что они теперь мейнстрим. Утрирую, конечно, но скорость превращения версий дотнетов в legacy многих пугает (и я среди них).

Короче, смотрите на свои потребности и думайте головой. Идеальной ОС нет. Linux ужасный. Windows отвратительный. MacOS дурацкий.

P.S. Вообще-то я хотел ограничиться только предыдущим абзацем, но внезапный приступ графоманства заставил написать развернутое вступление.

(2 голосов, средний: 5.00 из 5)

 Loading ...

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

Итак, язык программирования — это инструмент, с помощью которого создаются программы (да, я сегодня за К.О.). Как и всякий инструмент, он характерен тем, что:

• предназначен для решения определенного круга задач;
• имеет некое соотношение «удобство — сложность освоения — производительность труда — качество продукта».

Круг задач, решаемых с помощью инструмента, не является четко очерченным. Штыковая лопата замечательно подходит для изготовления небольших ям. Еще ей можно недурственно раскроить чей-то череп. Можно косить ею траву. Саперную лопатку можно метать на небольшие расстояния. При достаточном желании можно даже лопатой играть в большой теннис. Но все же первичная область использования, в которой лопата раскрывает свои лучшие качества, — копание ям.

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

Ладно, хватит аналогий.

Возьмем множество сферических программистов в вакууме. Для каждого языка программирования тогда будут более-менее соблюдаться следующие утверждения:

• время на изучение языка до определенного уровня = константа 0;
• удобство использования = (константа 1 для данного класса задач и языка)*sqrt(уровень владения);
• производительность труда = (константа 2 для данного класса задач и языка)*sqrt(уровень владения);
• качество результата = (константа 3 для данного класса задач и языка)*sqrt(уровень владения);
• прочие параметры по аналогии.

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

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

• системное программирование: ассемблеры, C, C++;
• высокопроизводительные вычисления: ассемблеры, C, C++;
• параллельные вычисления: C, C++, Erlang, C#, …;
• веб-приложения: PHP, Perl, Python, Java, Ruby, JavaScript;
• корпоративные приложения: C#, Java;
• массовые настольные приложения: C++, C#, Delphi;
• игры: С, С++, ActionScript, …;
• вспомогательные и встраиваемые сценарии: bash, Perl, Python, TCL, Lua, …

Этот список я брал более-менее из головы, но, думаю, недалеко ушел от истины.

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

Хорошим примером такой связки может быть Python+C. Они оба в плане синтаксиса несложные, но при этом первый имеет мощную библиотечную поддержку, но нетороплив, а второй позволяет выжать из компьютера все соки, но писать на нем большие программы — та еще радость (хотя опенсорсники придерживаются иного мнения). На таком тандеме можно написать почти все что угодно. На Python — GUI и основную логику, на C — низкоуровневую реализацию. Бхай-бхай.

Другой вариант — путь обобщения. Будут развиваться универсальные языки, которые обеспечит разумный компромисс между упомянутыми выше константами. Это может быть C++0x, ускоренный Python, упрощенный Perl или даже потихоньку всплывающий из пучин и обещающий всех порвать Haskell. C# — сомневаюсь. LINQ и вообще стремление к декларативщине — хорошее направление, но будет непросто преодолеть стереотип C# → Microsoft → отсутствие кроссплатформенности.

Этот вариант плох тем, что, как ни крути, специализированный язык в своей области эффективнее универсального.

Какой путь выбрать? А хрен его знает. Решайте сами.

(Еще не оценили)

 Loading ...

Некая усредненная функция обычно занимается чем-то таким:

1. Получает/захватывает/выделяет необходимые для работы ресурсы.
2. Выполняет содержательные действия.
3. Освобождает ресурсы.

На каждом из предыдущих этапов вдобавок должно выполняться обнаружение и обработка ошибок. И вот здесь-то и начинается самое интересное. Казалось бы, нет ничего сложного. Ну, обнаружили ошибку. Ну, обработали. В чем проблема-то? А проблема в деталях. Могут иметь место такие, например, случаи:

1. Функция получает не один ресурс, а N. Соответственно, все полученные ресурсы нужно освободить. А если при получении i-го ресурса произошла ошибка, то нужно освободить только ресурсы 0…i-1.
2. Если в содержательных действиях происходит ошибка, то перед освобождением ресурсов может понадобиться эту ошибку как-то обработать. Хорошо если такая ошибка может возникнуть только в одном месте — прямо там и обработаем. А что если в разных местах могут возникнуть ошибки, требующие одинаковой обработки? Еще после возникновения ошибки надо как-то покинуть содержательный код.
3. Если ошибка происходит в цикле со вложенностью 2 и более, то надо как-то все эти циклы покинуть.
4. Будем предполагать, что обработка ошибки не ограничивается возвратом кода ошибки, а включает какую-то более сложную обработку: запись в лог, выдача сообщений и т.п.

А еще мы хотим, чтобы наш код нормально читался, быстро работал и был пригоден для дальнейшего расширения. Такие вот мы противоречивые. Что делать будем? Есть несколько вариантов.

Вариант 0, «тупой»

Что думаю, то и пишу.

int function(...) {
    // ...здесь объявления переменных...
    if (get_res1(&res1))
        return ERROR1;
    if (get_res2(&res2)) {
        release_res1(&res1);
        return ERROR2;
    {
    // ...
    if (get_res25(&res25)) {
        release_res1(&res1);
        release_res2(&res2);
        // ...
        release_res24(&res24);
    }
    // ...какой-то содержательный код...
    // ...ошибка!
    if (error) {
        release_res1(&res1);
        release_res2(&res2);
        // ...
        release_res25(&res25);
        return SOME_ERROR;
    }
 
    release_res1(&res1);
    release_res2(&res2);
    // ...
    release_res25(&res25);
 
    return 0;
}

Плюсы: не обнаружены.

Минусы:

• массовое дублирование кода; чем больше ресурсов, тем больше дублирования;
• выход из функции в различных точках;
• ужасно читается;
• большие затраты на модификацию.

Вариант 1, «правильный»

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

int function(...) {
    struct data data;
    int r_code;
 
    r_code = get_resources(&data);
    if (!r_code) do_work(&data);
    if (r_code) handle_error(r_code, &data);
    release_resources(&data);
 
    return r_code;
}

Что там делают функции get_resources(), do_work(), handle_error() и release_resources() — нам неинтересно. Конечно, приведенный выше код — всего лишь демонстрация идеи. Очевидно, если все функции писать в таком духе, то до нижнего уровня, который, собственно, и делает фактическую работу, мы никогда не дойдем. Так и погрязнем в бесконечных слоях абстракций. Поэтому вместо do_work() обычно пишется компактный код, выполняющий требуемую работу, но без излишнего углубления в детали.

Плюсы:

• компактный код, хорошая читабельность;
• возможность повторного использования (например, функции обработки ошибок);
• одна точка выхода;
• хорошо поддается рефакторингу.

Минусы:

• относительно низкая эффективность;
• наличие синтетической структуры данных (struct data), хранящей состояние ресурсов.

Вариант 2, «тру-хакерский»

Настоящие хакеры не боятся goto. Настоящие хакеры плевать хотели на предрассудки. Мнение о вредности goto было специально распространено ими среди начинающих; goto в коде хакера — как катана в руках самурая: новичок может покалечить себя, а мастер — всех остальных.

int function(...) {
    // ...здесь объявления переменных...
 
    if (get_res1(&res1)) {
        ret = ERROR1;
        goto exit;
    }
    if (get_res2(&res2)) {
        ret = ERROR2;
        goto exit1;
    }
    // ...
    if (get_res25(&res25)) {
        ret = ERROR25;
        goto exit24;
    }
    // ...какой-то содержательный код...
    // ...ошибка!
    if (error) {
        ret = SOME_ERROR;
        goto error;
    }
    // ...
    goto exitOK;
 
error:
    // ...
 
exitOK:
    release_res25(&res25);
exit24:
    release_res24(&res24);
// ...
exit2:
    release_res2(&res2);
exit1:
    release_res1(&res1);
exit:
    return ret;
}

Идея схожа с предыдущим вариантом: локализовать места обработки ошибок и освобождения ресурсов. За счет fallthrough-стиля освобождение происходит очень изящно. Главная проблема при использовании goto для обработки ошибок и освобождения ресурсов — соблюдать меру. Не зря ведь в моем примере 25 ресурсов: в случае использования варианта №1 размер кода не зависит от их количества, здесь же мы получаем спагетти. Использование goto позволяет сократить код по сравнению с вариантом №0, но таит в себе опасность бесконечного увеличения размера функции, так как возможности рефакторинга здесь ограничены.

Такой подход можно встретить, например, в ядрах Linux и FreeBSD.

Плюсы:

• неплохая читабельность при аккуратной реализации;
• высокая эффективность;
• одна точка выхода.

Минусы:

• ограниченные возможности рефакторинга: части функции жестко связаны между собой переходами;
• при дальнейшем развитии функции она может стать плохо читаемой.

Вариант 3, «gotoфобский»

Еще один вариант, также часто встречающийся в реальном коде, — использование цикла в качестве конструкции, ограничивающей «зону безошибочного выполнения», и оператора break в качестве аналога goto из предыдущего варианта.

int function(...) {
    // ...здесь объявления переменных...
 
    do {
        if (get_res1(&res1)) {
            ret = ERROR1;
            break;
        }
        if (get_res2(&res2)) {
            ret = ERROR2;
            break;
        }
        // ...
        if (get_res25(&res25)) {
            ret = ERROR25;
            break;
        }
        // ...какой-то содержательный код...
        // ...ошибка!
        if (error) {
            ret = SOME_ERROR;
            break;
        }
        // ...
    } while(0);
 
    if (ret)
        ret = handle_error(ret, ...);
 
    if (res1_allocated(&res1))
        release_res1(&res1);
    if (res2_allocated(&res2))
        release_res2(&res2);
    // ...
    if (res25_allocated(&res25))
        release_res25(&res25);
 
    return ret;
}

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

Плюсы:

• отсутствует goto;
• слабая связность фрагментов функции, хорошо поддается рефакторингу;
• одна точка выхода.

Минусы:

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

Итого

Конечно, можно придумать еще мульён вариантов, один другого краше. Есть даже отдельная когорта любителей «метапрограммирования» (тыц, тыц). Я такие вещи не понимаю и не одобряю. Если уж есть такая тяга к синтаксису try-catch, то почему бы не пользоваться C++? В подавляющем большинстве случаев нет причины, которая позволяла бы пользоваться C, но исключала возможность использования C++ (хотя у меня именно такой редкий случай).

Чем же пользоваться? Мое мнение такое:

• всегда писать согласно варианту 1;
• если в результате работает слишком медленно, переписать отдельные функции (или даже модули) по варианту 2.

Жду гневные, но конструктивные комментарии.

(Еще не оценили)

 Loading ...

Программисты

Давным-давно жили-были Программисты. Были они умные, знали дофига чего такого, что обычным людям ни в жисть не понять, и было их мало. Оттого спросом они пользовались необычайным, зарабатывали кучу денег и вообще считались уважаемыми людьми. Еще были Пользователи, которые тоже умели программировать. Даже больше того, в то время собственно пользование компьютером заключалось в написании для него программ. Каждому Пользователю приходилось учить Фортран или Бейсик, иначе компьютер превращался просто в бесполезный предмет интерьера. Конечно, до уровня Программистов Пользователям было как пешком до Луны, потому что для Пользователя программирование было лишь инструментом, подспорьем в проведении необходимых вычислений и анализа, тогда как Программист занимался написанием программ профессионально. Короче говоря, было такое счастливое время, и все были довольны. Но Программисты все же были круче.

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

Да, вузы исправно каждый год выпускают тысячи молодых специалистов информационных специальностей. Но вот ведь какой парадокс: учили студента на Программиста, а получился Пользователь. Потому что воспитать Программиста может только другой Программист, а таких почти не осталось. Замкнутый круг.

Софт

Но это только одна сторона. Если посмотреть на рынок ПО, то несложно заметить, что ничего нового на нем фактически не появляется. Были эпохальные продукты вроде Windows, Office, 1C Что-То-Там и тому подобных монстров, которые закрыли собой гигантские ниши. Все! Нужно просто признать: эпоха разработки массового софта заканчивается. Все, что нужно среднестатистическому пользователю, уже написано. Зачем же тогда Microsoft год за годом печет новые Офисы и Винды? Что, старые чем-то плохи? Нет! Просто им хочется кушать. Поэтому они развешивают тонны маркетинговой лапши на нежные юзерские уши, лишь бы только кто-нибудь купил их новый Офис. Который от N предыдущих версий отличается только по-другому расположенными кнопками и приведенной в соответствие с веяниями моды цветовой гаммой. Без сомнения, за это стоит отдавать триста баксов!

Конечно, я преувеличиваю. В мире есть еще что разрабатывать.

• Веб-приложения. Сейчас «программист» уже в головах обывателей является синонимом «веб-программиста». Только вот беда — вердикт «уже написано» все чаще звучит и здесь. Народ уже не знает, что бы такое написать, поэтому пишет всякую ерунду, благо процесс ее создания упростился невероятно. Операционная система в браузере? Не смешите.
• Корпоративный софт. Опять-таки, загибающаяся область. Один универсальный инструмент (1С, SAP) и толпа низкоквалифицированных адептов (1С-«программист», хо-хо) легко заменяет большинство корпоративок. Остаются лишь только всякие банки, авиаперевозчики и т.п., которые поступили мудро, придумав настолько сложные бизнес-процессы, что хрен напишешь обобщенный инструмент. А если поднапрячься и все же написать, получится VisualStudio.
• Специфический софт. Драйверы, управляющий софт, firmware. Пожалуй, здесь пока еще все нормально. Появляются новые железки и комплексы — должен появиться и софт для них, никуда не денешься.

Итого

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

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

С другой стороны, программисты все еще считают себя самыми востребованными специалистами на свете и всячески это мнение поддерживают. Вместе с тем их профессионализм стремительно падает (см. выше), а самооценка столь же стремительно растет. «Российских Программистов» это касается в первую очередь. Г-н Медведев вон считает, что «наши программисты — самые программистые». А на деле выходит, что они (мы) сливаем по всем статьям западным коллегам, а денег хотим много.

Так что готовьтесь. Пройдет еще несколько лет (думаю, от 5 до 15), и запас инерции кончится. Собственно, зарплаты программистов уже падают (и в рублях, и в долларах), как и количество вакансий. А скоро мы получим:

• в разы меньшее количество рабочих мест;
• гораздо более высокие требования к квалификации;
• жесточайшую конкуренцию.

Приходите через пять лет, проверим.

(4 голосов, средний: 4.00 из 5)

 Loading ...