> а как насчёт динамической линковки с менее стабильными библиотеками? Или в Windows особая магия,
Да, это же известная проблема DLL hell. Особой магии нет: политика партии в том, чтобы тащить все версии динамических библиотек в дистрибутиве.
Но этот механизм худо-бедно заработал начиная с XP (вроде бы?), так что, конечно, полной обратной совместимости с более ранними версиями ОС ожидать трудно. Но чем дальше, тем должно быть лучше.
Мне кажется, это какое-то умозрительное соображение. Если Linux «максимально быстро движется вперёд», то функциональность линуксового софта должна быть уже где-то в космосе, ну или, по крайней мере, на голову опережать любой Windows-софт, однако на практике этого не происходит.
Полагаю, что вы напрасно между строк пишете «если вдруг проект больше не собирается или не запускается на новой версии ядра, то его кто-нибудь поправит». В этом-то и проблема: постоянно приходится бежать изо всех сил, чтобы хотя бы оставаться на месте. Я так не хочу. Я хочу написать один раз, а потом заниматься уже другими функциями, а не бесконечно всё переделывать только ради того, чтобы оно хотя бы компилировалось.
Самая характерная черта современности — это то, что у каждого она своя. Например, в моём мире очень важно знать, сколько какая папочка занимает, и далеко не всё в онлайне. А менеджером закачек я пользуюсь ежедневно на мобильнике для скачивания подкастов — поставил сразу несколько в очередь, и они преспокойно в фоне скачиваются, да ещё и в несколько потоков, а в один поток тормозит и обрывается, да.
Да, я понимаю. Читалки, собственно, интерфейс и анализируют, верно?
Наверно, слепые большое спасибо сказали Эпплу за то, что их любимая читалка сломалась.
> их пометили как депрекейтед, уже нужно было смотреть документацию
Кому нужно было? Разработчиком стороннего софта, на который я опираюсь? Людям на Stackoverflow, которые годами советовали пользоваться? Да, пожалуй, вы правы, но мне от этого не легче.
Да и вообще, база кода растёт, получается, что с каждым таким движением со стороны Apple мне придётся исправлять всё больше и больше. В конце концов, я только этим и буду заниматься.
Из последнего, с чем столкнулся. Есть такая система автоматизированного тестирования GUI — Appium. Очень хорошая штука. Она виртуально нажимает кнопки и проч. с помощью UI Automation. Как найти кнопку? В гугле с 99% вероятностью вы натолкнётесь на примеры, которые используют accessibility identifiers, т.е., видимо, как раз идентификаторы, для программного анализа интерфейса и предусмотренные. Убил, наверно, дня три на возню с этой штукой — не работает!
И я до сих пор не знаю, почему. Обнаружил сначала, что эти функции accessibility были помечены как deprecated, а теперь на сайте apple developer вообще в документации они никак не указаны. У них вроде как другая модель используется, но весь интернет забит старыми примерами, а для нового интерфейса нужен совершенно другой fork Appium и документация, которую неясно где брать.
Её поддерживать затем, что выходная программа — это всего лишь вершина айсберга, за которой стоит масса инструментария, например, для тестирования. Когда я запускаю автотест или какой-то внутренний tool, меня производительность мало заботит. Что меня заботит, так это отсутствие необходимости что-либо переписывать. Кроме того, я могу опираться на чужой код, который тоже может далеко не оперативно быть переписан.
Короче говоря, иметь лучше, чем не иметь. Но повторюсь, я же не говорю, что Эппл не имеет права на такую политику. Имеет. Но как разработчик я выражаю своё фи, потому что мне от их политики больше вреда, чем пользы.
А вы не задумывались, зачем его тогда вообще добавляли?
Код может быть сколько угодно тормозящим или нежелательным, тем не менее, он был добавлен и описан в документации, и это значит, что тысячи людей будут на этот код рассчитывать. Вы предлагаете мне войти в их положение, но кто войдёт в моё положение?
Как только появляется альтернатива, устаревший и нежелательный код перестаёт использоваться сам собой. В Windows есть масса API функций, о которых практически нигде не пишут, потому что есть альтернативы получше — «желательные» и не тормозящие. Тем не менее, если разработчику очень надо, он может воспользоваться и старым интерфейсом, бывает.
С сертификатами проблем нет, когда нет сертификатов, это ещё более простое решение.
Пусть юзеров переводят на современные iOS сколько угодно, но зачем ломать обратную совместимость? Претензия ведь именно в этом. Тут получается ровно наоборот: мне как раз нужно «поддерживать устаревший код», т.е. постоянно его обновлять и переписывать, чтобы он просто продолжал работать, в то время как я хотел бы забыть о нём — сидит он где-то внутри и делает своё дело годами без каких-либо усилий с моей стороны.
Вот понимаете, если вы работаете под маком на последней версии XCode и пишете на Swift, то проблем у вас быть и не должно, на это они и рассчитывают.
А у меня, например, есть приложение на Unity с рядом native plugins, написанных на C++. И ещё система автоматизированного GUI тестирования. Вот это, доложу я вам, совсем непросто. Приходится прибегать к приёмам, граничащим с чёрной магией (но при этом абсолютно законным и документированным), но поскольку таких как я не так много, Apple считает для себя возможным просто нас игнорировать. В этом смысле я горячий и яростный фанат Microsoft (о боги, что я говорю...), потому что эти ребята до последнего поддерживают самые древние API.
В конце концов, кроме непосредственного приложения, которое идёт пользователю, есть подводная часть айсберга: подсистемы тестирования, инструментарий и прочее. Это всё писалось очень давно, и обновлять смысла никакого нет — работает, и слава богу. Особенно печально оказывается, когда инструмент обращается к XCode и «дружит» только с определённой версией. При этом другой инструмент, разумеется, «дружит» только с другой…
Собственно, перечисленное и подразумеваю: чтобы откомпилировать программу под Windows или Linux, мне достаточно компилятора любого языка программирования под любой платформой. Откомпилировал, скопировал, запустил, job done.
Здесь сталкиваемся с массой ограничений: на каком языке писать, под какой платформой и какими инструментами разрабатывать, всякая дополнительная возня с сертификатами (массу времени на это убил). А потом выходит новая версия iOS, и workflow превращается в тыкву, потому что, оказывается, ты где-то использовал функцию, которую выпилили (настолько жёстко, что она даже из документации исчезла), и теперь крутись как умеешь, мы тебе не помощники. Ну и всякие доп. требования туда же, например, иметь обязательно 32- и 64-разрядные версии. Короче говоря, мне это всё неинтересно, я хочу писать под привычной платформой на привычном инструменте, и не переделывать старый код каждый год, чтобы он хотя бы продолжал работать. Это трата моего времени и моих сил (= недружелюбие).
В этом смысле Android лично мне представляется куда менее капризным, хотя и в нём своих проблем хватает, конечно же.
Меня как разработчика тоже раздражает неимоверно. Покупать и настраивать мак только ради того, чтобы компилировать под iOS — это какое-то выкручивание рук; вся эта катавасия с сертификатами уже порядком поднадоела; периодический перевод всего и вся на последнюю версию с ломкой обратной совместимости — вообще печаль-печаль, такое ощущение, что им мёду не надо, лишь бы подгадить.
Да, они имеют право так себя вести. Но и я своё мнение высказать тоже право имею. Платформа у них крайне недружелюбная, и если по какой-то причине их бизнес покатится под горку, разработчики радостно свалят в первых рядах, и плакать не будет никто.
Я достаточно часто участвую в академических конференциях (как слушатель и как докладчик), и к сожалению, да, приходится признавать, что основная масса выступающих довольно плохо готовится к презентации.
С перечисленными рекомендациями согласен, хотя все они практически сводятся к одной мысли: избегайте мусора. Даже здесь в комментариях не совсем понимают суть, рассуждают о «ненужной политкорректности» и т.п., хотя речь, конечно, не о политкорректности, а просто о том, что говорить надо по существу. Все эти фразы вроде «нетрудно заметить» или «каждому ясно», или «если кто забыл» не несут никакой смысловой нагрузки. Если их выбросить все, смысловое содержание не изменится никак.
Самый быстрый способ донести мысль до аудитории — это просто раздать продуманный документ на бумаге. Читаем мы быстрее, чем слушаем, если что не поняли, можем перечитать, остановиться, полистать распечатку. Сейчас же не стародавние времена, изыскать принтер и бумагу — не проблема. Соответственно, смысл слушать (а не читать) появляется благодаря харизме лектора, его умению голосом, интонацией, скоростью, жестом подчеркнуть главное, убедить, донести.
А вот с этим как раз и проблема: слушаешь иной доклад и думаешь, ну вот зачем я всё это слушаю? Ведь текст был бы куда короче и доходчивее. И проблем масса, иной раз диву даёшься, как люди ухитряются не думать о самых простых вещах. Например, пишут в Powerpoint тексты каким-нибудь шрифтом 12 размера или пролистывают слайды со сложным содержанием (список литературы, таблицы) на такой скорости, на которой освоить их решительно невозможно. Или вставляют скриншоты с мелкими текстами, которые совершенно не видны из зала. Или весьма слабо представляют себе, сколько времени по факту занимает их речь.
Мой любимый раздражитель — это первый слайд типа Outline, на котором перечислены безликие пункты, подходящие абсолютно к любой презентации (вроде Motivaton -> Approach -> Results -> Conclusion). Удивительно, что люди не чувствуют, как тратят время на абсолютнейшую ерунду.
При этом я не говорю, что доклад должен быть сухим и обезличенным, вовсе нет. Можно и своё мнение высказать, и шутку припомнить — но всё к месту. Если я говорю, что занимаюсь своей темой просто потому что она мне нравится — это ОК, имею право (хотя всё равно надо объяснить, почему тема должна быть интересна и слушателю тоже). Если же доказываю работоспособность некоторого метода, то тут шутки и пассионарный тон неуместны — нужны чёткие доказательства, внятно и структурировано изложенные.
Мне кажется, автор затрагивает очень интересную тему, но немного драматизирует.
Личные воспоминания о серьёзных проектах от микроконтроллеров до Qt в очередной раз показывают, что наша индустрия всё ещё молода, ведь в самом деле, как уже отмечали, невозможно себе представить, чтобы сегодня хирург делал операцию на сердце, а завтра — на мозге.
Получается, что мы работаем несколько «по-ковбойски»: что-то делаем, оно как-то работает, никто не понимает как, и слава богу. Макконнелл считает, что всё будет двигаться в сторону более строгой бюрократической системе разделения работ на основе лицензируемости. Ну, мы уже видим это на примерах всяких сертификатов Oracle или IBM, но в целом, как мне кажется, он впадает в другую крайность.
Я думаю, что проблема будет решаться по кусочкам. Во-первых, есть вопрос денег. Если вы строите у себя амбар на участке, нет смысла нанимать архитектурное бюро и заставлять инженеров просчитывать сопромат. Упадёт — ну и ладно, новый поставим. Так и у нас, глядя на поделия, то есть, гм, инструментарий для внутренних нужд, можно потерять веру в человечество; но мы же понимаем разницу между амбаром на заднем дворе и продуктом на продажу. При этом и вопрос денег тоже решается по-разному. Скажем, китайцам, которые производят ширпотреб десятками или сотнями тысяч единиц, почему-то проще перевести инструкцию гугл-транслейтом, вместо того, чтобы нанять хорошего переводчика всего на один день (!) Видимо, не считают эти космические затраты целесообразными, что тут сказать. В IT ведь всё то же самое: ну хорошо, наймите отдельного специалиста, который разбирается досконально в Qt (и больше ни в чём), но сначала решите, стоит оно того или нет.
Во-вторых, есть вопрос интерфейсов, документированности и обязательств. Пример с «магической строкой» показывает, что не всё здесь ладно, потому что не хватает культуры производства, и это не только авторов Qt проблема, пока попросту нет всеми принятого подхода, и каждый крутится как умеет. Скажем, мне нравится (хотя бы на идейном уровне) подход к документации библиотеки C++ STL. Для каждого алгоритма указаны чёткие требования по входным данным, гарантии выходных данных и асимптотическая сложность алгоритма. При этом почти везде гарантируется, что самостоятельная реализация того же алгоритма вряд ли будет намного лучше, т.е. мысли «переписать STL» в большинстве случаев возникать не должно. То есть мы имеем чётко определённые «кирпичи» с заданными характеристиками, и лезть внутрь такого «кирпича» совершенно незачем. Сравните это с ситуацией в Python, где сам автор языка последовательно перебирает различные «волшебные» строки с целью ускорить алгоритм (не всегда представляя себе ожидаемый результат).
Иными словами, разделение ответственности и ликвидация «волшебных» строк в целом возможны. Но всё это требует больших усилий, денег и дисциплины. Кому-то удаётся лучше, кому-то — так себе. В общем, ужас, но не ужас-ужас-ужас.
Я думаю, что проблема в тайм-ауте: браузер считает, что страничка долго не грузится, и забивает на рисунки. Где-нибудь есть эта настройка? Когда он решает, что хватит ждать, пора вывести пустой прямоугольник?
Поскольку моя прошлая жалоба осталась без комментария, продублирую:
Только у меня страницы с большим количеством рисунков (например, ЖЖ пост с картинками) загружается нереально медленно и очень рано сдаётся (вместо картинок показывает заглушки)? Кстати, непонятно, почему в контекстном меню нет пункта «перезагрузить картинку», это же достаточно частая история. Аналогично, через раз работают сайты вроде google maps и google поиск картинок.
Я даже не понимаю, это конкретно моя проблема или косяк браузера, и что с этим делать.
> а на территории пяти северных стран — здесь этот тренд не просто сильный, а очень сильный
По моей логике получается тогда, что эти северные страны последние 20 лет были в коматозе, и к 2006 году ещё не успели адаптироваться к ситуации. Но ведь это не так.
Вот смотрите, я учился в Финляндии в магистратуре в 2002-2004 годах. Общался с самым разным народом — физиками, биологами, специалистами в лесной промышленности. Уже тогда умение пользоваться компьютером (и не просто пользоваться, а хоть немного программировать) для всех этих ребят было очевидной частью их работы.
То есть опять же, мой тезис состоит в том, что тренда нет, потому что мы уже находимся на гребне этого тренда. Ну да, может, мы ещё не в самом пике, но нельзя сказать, что вот не было программистов, а сейчас они начнут появляться в огромных количествах. Они есть, и уже достаточно давно.
Да, это же известная проблема DLL hell. Особой магии нет: политика партии в том, чтобы тащить все версии динамических библиотек в дистрибутиве.
Но этот механизм худо-бедно заработал начиная с XP (вроде бы?), так что, конечно, полной обратной совместимости с более ранними версиями ОС ожидать трудно. Но чем дальше, тем должно быть лучше.
Полагаю, что вы напрасно между строк пишете «если вдруг проект больше не собирается или не запускается на новой версии ядра, то его кто-нибудь поправит». В этом-то и проблема: постоянно приходится бежать изо всех сил, чтобы хотя бы оставаться на месте. Я так не хочу. Я хочу написать один раз, а потом заниматься уже другими функциями, а не бесконечно всё переделывать только ради того, чтобы оно хотя бы компилировалось.
Наверно, слепые большое спасибо сказали Эпплу за то, что их любимая читалка сломалась.
Кому нужно было? Разработчиком стороннего софта, на который я опираюсь? Людям на Stackoverflow, которые годами советовали пользоваться? Да, пожалуй, вы правы, но мне от этого не легче.
Да и вообще, база кода растёт, получается, что с каждым таким движением со стороны Apple мне придётся исправлять всё больше и больше. В конце концов, я только этим и буду заниматься.
И я до сих пор не знаю, почему. Обнаружил сначала, что эти функции accessibility были помечены как deprecated, а теперь на сайте apple developer вообще в документации они никак не указаны. У них вроде как другая модель используется, но весь интернет забит старыми примерами, а для нового интерфейса нужен совершенно другой fork Appium и документация, которую неясно где брать.
Короче говоря, иметь лучше, чем не иметь. Но повторюсь, я же не говорю, что Эппл не имеет права на такую политику. Имеет. Но как разработчик я выражаю своё фи, потому что мне от их политики больше вреда, чем пользы.
Код может быть сколько угодно тормозящим или нежелательным, тем не менее, он был добавлен и описан в документации, и это значит, что тысячи людей будут на этот код рассчитывать. Вы предлагаете мне войти в их положение, но кто войдёт в моё положение?
Как только появляется альтернатива, устаревший и нежелательный код перестаёт использоваться сам собой. В Windows есть масса API функций, о которых практически нигде не пишут, потому что есть альтернативы получше — «желательные» и не тормозящие. Тем не менее, если разработчику очень надо, он может воспользоваться и старым интерфейсом, бывает.
Пусть юзеров переводят на современные iOS сколько угодно, но зачем ломать обратную совместимость? Претензия ведь именно в этом. Тут получается ровно наоборот: мне как раз нужно «поддерживать устаревший код», т.е. постоянно его обновлять и переписывать, чтобы он просто продолжал работать, в то время как я хотел бы забыть о нём — сидит он где-то внутри и делает своё дело годами без каких-либо усилий с моей стороны.
А у меня, например, есть приложение на Unity с рядом native plugins, написанных на C++. И ещё система автоматизированного GUI тестирования. Вот это, доложу я вам, совсем непросто. Приходится прибегать к приёмам, граничащим с чёрной магией (но при этом абсолютно законным и документированным), но поскольку таких как я не так много, Apple считает для себя возможным просто нас игнорировать. В этом смысле я горячий и яростный фанат Microsoft (о боги, что я говорю...), потому что эти ребята до последнего поддерживают самые древние API.
В конце концов, кроме непосредственного приложения, которое идёт пользователю, есть подводная часть айсберга: подсистемы тестирования, инструментарий и прочее. Это всё писалось очень давно, и обновлять смысла никакого нет — работает, и слава богу. Особенно печально оказывается, когда инструмент обращается к XCode и «дружит» только с определённой версией. При этом другой инструмент, разумеется, «дружит» только с другой…
Здесь сталкиваемся с массой ограничений: на каком языке писать, под какой платформой и какими инструментами разрабатывать, всякая дополнительная возня с сертификатами (массу времени на это убил). А потом выходит новая версия iOS, и workflow превращается в тыкву, потому что, оказывается, ты где-то использовал функцию, которую выпилили (настолько жёстко, что она даже из документации исчезла), и теперь крутись как умеешь, мы тебе не помощники. Ну и всякие доп. требования туда же, например, иметь обязательно 32- и 64-разрядные версии. Короче говоря, мне это всё неинтересно, я хочу писать под привычной платформой на привычном инструменте, и не переделывать старый код каждый год, чтобы он хотя бы продолжал работать. Это трата моего времени и моих сил (= недружелюбие).
В этом смысле Android лично мне представляется куда менее капризным, хотя и в нём своих проблем хватает, конечно же.
Да, они имеют право так себя вести. Но и я своё мнение высказать тоже право имею. Платформа у них крайне недружелюбная, и если по какой-то причине их бизнес покатится под горку, разработчики радостно свалят в первых рядах, и плакать не будет никто.
Доклад — это не «личное общение», а зачастую монотонное и занудное изложение, при котором количество невербальной информации стремится к нулю.
> и получить галочку в личное дело
Совершенно справедливо, но мы же тут обсуждаем честные попытки сделать хороший доклад, а не печальную реальность, в которой разное бывает.
С перечисленными рекомендациями согласен, хотя все они практически сводятся к одной мысли: избегайте мусора. Даже здесь в комментариях не совсем понимают суть, рассуждают о «ненужной политкорректности» и т.п., хотя речь, конечно, не о политкорректности, а просто о том, что говорить надо по существу. Все эти фразы вроде «нетрудно заметить» или «каждому ясно», или «если кто забыл» не несут никакой смысловой нагрузки. Если их выбросить все, смысловое содержание не изменится никак.
Самый быстрый способ донести мысль до аудитории — это просто раздать продуманный документ на бумаге. Читаем мы быстрее, чем слушаем, если что не поняли, можем перечитать, остановиться, полистать распечатку. Сейчас же не стародавние времена, изыскать принтер и бумагу — не проблема. Соответственно, смысл слушать (а не читать) появляется благодаря харизме лектора, его умению голосом, интонацией, скоростью, жестом подчеркнуть главное, убедить, донести.
А вот с этим как раз и проблема: слушаешь иной доклад и думаешь, ну вот зачем я всё это слушаю? Ведь текст был бы куда короче и доходчивее. И проблем масса, иной раз диву даёшься, как люди ухитряются не думать о самых простых вещах. Например, пишут в Powerpoint тексты каким-нибудь шрифтом 12 размера или пролистывают слайды со сложным содержанием (список литературы, таблицы) на такой скорости, на которой освоить их решительно невозможно. Или вставляют скриншоты с мелкими текстами, которые совершенно не видны из зала. Или весьма слабо представляют себе, сколько времени по факту занимает их речь.
Мой любимый раздражитель — это первый слайд типа Outline, на котором перечислены безликие пункты, подходящие абсолютно к любой презентации (вроде Motivaton -> Approach -> Results -> Conclusion). Удивительно, что люди не чувствуют, как тратят время на абсолютнейшую ерунду.
При этом я не говорю, что доклад должен быть сухим и обезличенным, вовсе нет. Можно и своё мнение высказать, и шутку припомнить — но всё к месту. Если я говорю, что занимаюсь своей темой просто потому что она мне нравится — это ОК, имею право (хотя всё равно надо объяснить, почему тема должна быть интересна и слушателю тоже). Если же доказываю работоспособность некоторого метода, то тут шутки и пассионарный тон неуместны — нужны чёткие доказательства, внятно и структурировано изложенные.
Личные воспоминания о серьёзных проектах от микроконтроллеров до Qt в очередной раз показывают, что наша индустрия всё ещё молода, ведь в самом деле, как уже отмечали, невозможно себе представить, чтобы сегодня хирург делал операцию на сердце, а завтра — на мозге.
Получается, что мы работаем несколько «по-ковбойски»: что-то делаем, оно как-то работает, никто не понимает как, и слава богу. Макконнелл считает, что всё будет двигаться в сторону более строгой бюрократической системе разделения работ на основе лицензируемости. Ну, мы уже видим это на примерах всяких сертификатов Oracle или IBM, но в целом, как мне кажется, он впадает в другую крайность.
Я думаю, что проблема будет решаться по кусочкам. Во-первых, есть вопрос денег. Если вы строите у себя амбар на участке, нет смысла нанимать архитектурное бюро и заставлять инженеров просчитывать сопромат. Упадёт — ну и ладно, новый поставим. Так и у нас, глядя на поделия, то есть, гм, инструментарий для внутренних нужд, можно потерять веру в человечество; но мы же понимаем разницу между амбаром на заднем дворе и продуктом на продажу. При этом и вопрос денег тоже решается по-разному. Скажем, китайцам, которые производят ширпотреб десятками или сотнями тысяч единиц, почему-то проще перевести инструкцию гугл-транслейтом, вместо того, чтобы нанять хорошего переводчика всего на один день (!) Видимо, не считают эти космические затраты целесообразными, что тут сказать. В IT ведь всё то же самое: ну хорошо, наймите отдельного специалиста, который разбирается досконально в Qt (и больше ни в чём), но сначала решите, стоит оно того или нет.
Во-вторых, есть вопрос интерфейсов, документированности и обязательств. Пример с «магической строкой» показывает, что не всё здесь ладно, потому что не хватает культуры производства, и это не только авторов Qt проблема, пока попросту нет всеми принятого подхода, и каждый крутится как умеет. Скажем, мне нравится (хотя бы на идейном уровне) подход к документации библиотеки C++ STL. Для каждого алгоритма указаны чёткие требования по входным данным, гарантии выходных данных и асимптотическая сложность алгоритма. При этом почти везде гарантируется, что самостоятельная реализация того же алгоритма вряд ли будет намного лучше, т.е. мысли «переписать STL» в большинстве случаев возникать не должно. То есть мы имеем чётко определённые «кирпичи» с заданными характеристиками, и лезть внутрь такого «кирпича» совершенно незачем. Сравните это с ситуацией в Python, где сам автор языка последовательно перебирает различные «волшебные» строки с целью ускорить алгоритм (не всегда представляя себе ожидаемый результат).
Иными словами, разделение ответственности и ликвидация «волшебных» строк в целом возможны. Но всё это требует больших усилий, денег и дисциплины. Кому-то удаётся лучше, кому-то — так себе. В общем, ужас, но не ужас-ужас-ужас.
Только у меня страницы с большим количеством рисунков (например, ЖЖ пост с картинками) загружается нереально медленно и очень рано сдаётся (вместо картинок показывает заглушки)? Кстати, непонятно, почему в контекстном меню нет пункта «перезагрузить картинку», это же достаточно частая история. Аналогично, через раз работают сайты вроде google maps и google поиск картинок.
Я даже не понимаю, это конкретно моя проблема или косяк браузера, и что с этим делать.
По моей логике получается тогда, что эти северные страны последние 20 лет были в коматозе, и к 2006 году ещё не успели адаптироваться к ситуации. Но ведь это не так.
Вот смотрите, я учился в Финляндии в магистратуре в 2002-2004 годах. Общался с самым разным народом — физиками, биологами, специалистами в лесной промышленности. Уже тогда умение пользоваться компьютером (и не просто пользоваться, а хоть немного программировать) для всех этих ребят было очевидной частью их работы.
То есть опять же, мой тезис состоит в том, что тренда нет, потому что мы уже находимся на гребне этого тренда. Ну да, может, мы ещё не в самом пике, но нельзя сказать, что вот не было программистов, а сейчас они начнут появляться в огромных количествах. Они есть, и уже достаточно давно.