"Узок круг этих революционеров. Страшно далеки они от народа" (c) В. И. Ленин.
QNX (тоже сильно сложно, но все же POSIX система). Solaris (аналогично - условно POSIX) до сих пор актуальна. Похороненная и живущая только в комментариях на LORе BSD (туда же) основа для Playstion. Ах да, еще macOs корнями упирается в нее же. И это только то, что на слуху и вспоминается на счет раз.
У Linux есть GPL и надзорные органы, которые не очень эффективно, но следят за ее соблюдением. Потому про Linux знают. Можно долго спорить, но "вирусная лицензия" GPL сильно мешает вашему же "могут ... все нужные linux specific APIs реализовать". Тут дело не в гордости. Обратный процесс тоже не очень идет. ZFS портируется с трудом. И да, опять все упирается в "гордости только чуть поубавить". Хотя в ту же BSD давно забрали.
Безусловно, основной прогресс в Linux. Причем прогресс настолько огромный, что уже начинает попахивать цепной реакцией и не очень понятно найдется ли на нее контролирующий стержень. Впрочем, это уже тема отдельного разговора. И я не хочу его начинать.
Если заранее известно про ограничение в 30 км/час зачем покупать спорткар? Если есть задача поставить мировой рекорд скорости, то конейнеровоз не выглядит подходящим решением.
Уникальная задача всегда имеет уникальное решение. А типовое решение всегда неудобный ни для кого компромисс. Главное искусство инженера ровно в том, что бы не путать эти сущности.
И тотальное забвение необходимости совместимости с MacOS, FreeBSD, Solaris, AIX, и кто там еще живой. Про Windows и говорить не стоит.
Смело, модно, молодежно.
Вообще говоря, posix с самого начала был "чемоданом без ручки". Примерно как знаменитый автомат Калашникова. Каждому конкретному бойцу он неудобен - масса, габариты, кучность, убойная сила.... Но для каждого рода войск и прочих неармейских подразделений своя модификация. При сохранении базовых принципов и взаимозаменяемости основных частей.
В этом смысле Linux, как альтернатива Posix ничего кроме улыбки не вызывает. Posix не запрещает clone() и прочие так любые вашему сердцу моменты. А если единственная целевая аудитория это Linux - ну и славненько.
Давайте так - каждое из утверждений имеет свои "за" и свои "против". В общем случае хочется думать, что если обозначенные проблемы реально являются проблемами они будут решены. Пусть и не в рамках языка С, который однажды окажется в учебниках по истории IT и редко где в реальной жизни.
Если вы хотите что-то реально поменять, пишите не комментарии, а статьи
Да, именно тут и есть замкнутый круг. Я могу рассказывать на работе молодому поколению. Как правило в режиме ответов на вопрос "что это было?", "а почему так нельзя?" или "а что так можно было"? Тогда появляются структурные и функциональные схемы железок, тогда появляются тайминги и прочие радости нашего уровня. Я честно пытался хоть из чего-то похожего сделать статью. Получается или слишком узко и нишево, или очередной пример такого вот варианта.
Ну или да... Ржут надо мной коллеги-схемотехники. Говорят ты за столько лет уже лекцию "радиоэлектроника для программистов" можешь снимать и на youutube выкладывать. Она и начинающим схемотехникам полезной окажется. За три поколения воспитанников отточил... Может правда как-нить заняться... Тогда может быть текстовая версия и здесь появится. Но пока есть интересная работа и тупо не до того... И это, пожалуй, самое главное.
Вообще получается парадоксальная ситуация - есть потребность в специалистах, но никто не знает как именно их готовить. Ибо инструмент один, а навык его использования оттачивается только в процессе работы. Я даже не знаю с чем бы сравнить... Ну, возможно, MIDI-клавиатура (синтезатор) в музыкальной студии против концертного рояля в консерватории. Т.е. инструмент один, а подход (и, безусловно, результат) разный. При чем и тот и другой результат востребованы. И принципиально нет каких-то серьезных ограничений, по которым пианист-виртуоз не смог бы записать на синтезаторе партии всех инструментов, или музыкант-клавишник современной популярной группы не смог бы исполнить условного Моцарта в условной консерватории, но... Эти миру сосуществуют рядом практически не соприкасаясь. Лишь изредка случается миграция в ту или иную сторону.
Похоже что пока так и останется. Меня на работе учили, я учу и мои последователи учить будут. Может оно и правильно. Ну а здесь будем ловить минусы от тех, кто идет параллельным путем.
На этом уровне как раз и формируется POSIX. Собственно здесь же он и начинает использоваться. В частности и для абстракций высшего уровня. И не только для самого языка С.
Что же до PostgreSQL или Nginx, то.... Может быть Legacy, а может быть разумный выбор инструмента для оптимального решения конкретной задачи.
Все меняется. Кто сейчас помнит самый популярный некогда почтовик sendmail? Уж даже не спрашиваю кто им пользуется... Так что когда становится реально надо, legacy переписывается.
первому языку не учат нигде, кроме как на работе, а с привычками, сформированными вторым, потом приходится бороться годами
Я вас категорически приветствую!
Да, черт возьми. Собственно по этой причине я и открыл эту ветку комментариев. С наивной надеждой хоть что-то поменять. Только вот... Конструктивный диалог получается разве что со старыми знакомыми. Понятно, что определение "канонический вариант" оно лукаво и не описывает суть проблемы. Но я не знаю как переформулировать более грамотно.
Радует, что понимание того, что язык С разный для разных задач есть не только у меня. Обидно, что нас крайне мало.
Так, собственно, отсюда и вопрос... Дело ведь в том, что язык С изначально пытался занять очень много стульев сразу и претендовал на роль панацеи. Мы не будем тыкать в современные языки, которые ведут себя ровно так же - это проходит со временем. Вот и С довольно быстро разделился.
"Кроссплатформенный ассемблер с элементами структурного синтаксиса" (с) - это современный язык С. Все остальные его реинкарнации потихоньку сходят на нет, уступая место более удобным инструментам. И POSIX в таком варианте наше все. А это read/write, а еще atoi/atof и парные им ftoa/ftol.
"Переносимый между платформами язык С" - это безусловно K&R. В таком варианте безусловно printf/scanf, с соответствующими слоями абстракции. Ну и понятно, что в конце-концов именно "Переносимы С" обрел потомка виде С++ и сильно сдал свои позиции.
Вот отсюда и вопрос. Правда ли, что K&R с их "переносимым С" стоит сегодня рассматривать как канонический вариант использования языка. Да, безусловно, если еще комплект system-utils, sed, find, gawk и прочего прикладного софта нижнего уровня, который написан на таком С. Но все же, современный С это сильно больше язык загрузчиков, ядер операционных систем и драйверов. Другими словами тот самый "кроссплатформенный ассемблер". Или это у меня профдеформация и на самом деле все не так?
Я не спорю с метрами. Я спрашиваю мнение общественности. Особенно той ее части, что работает преимущественно с языком С и спускается к ассемблеру по мере необходимости.
Тем более, что это далеко не идеал, если копнуть поглубже. Например const перед char в общем случае был бы весьма уместен.
Все хорошо. И в целом не новость. Едиственный вопрос, который меня всегда слегка заботит, это почему printf? Разве канонический HelloWorld на C не должен быть таким
Ух! Как концом 90-ых пахнуло.... DECT, связь на производстве.... Siemens, Gigaset...
Только вот что ж так мало-то? Как автоматизировали регистрацию трубок? Как связывали между собой базы? Как добивались бесшовного роуминга по всей территории склада? И добились ли вообще? А если добились то для всех ли абонентов? Как боролись с "горячими точками" в плане количества соединений на единицу площади?
В конце 90-ых это было возможно только с очень продвинутыми ISDN станциями, которых почти нигде не было, и которые всеми силами пытались создать сами (довольно успешно, к слову). Правда тогда DECT очень быстро вышел из употребления для этих целей. GSM позволил не строить собственную сеть, а пользоваться операторской. При этом накрывая достаточные площади.
Вообще, DECT очень интересная система. Да, ее знают (знали?) в основном по домашним трубкам. Но вообще-то французский армейский комплекс Felin имел (имеет?) систему внутренний связи как раз на базе DECT. В целом, это фактически GSM в миниатюре. Она именно так и задумывалась, но... В силу ряда причин скатилась к простеньким домашним трубкам.
Слушайте, а научите меня купить домен за 2-4 бакса в год, так чтоб его можно было к VPS прицепить. Только так, чтоб домен реально мой был, а не "премиум" от dyndns'а - который элементарно завтра закроется и с концами.
Я не знаток таких вещей, но как-то попытался и дальше начинается - домен пожалуйста, и ценник примерно такой, но сразу обязательно резервный DNS сервер, панель управления и прочее, прочее, прочее. По итогу не 2, а хорошо если 50.
"За доллар в месяц вложение в личный бренд и технологическую независимость окупится многократно." - только без собственного доменного имени независимость будет далеко не полной, а с ним будет далеко не доллар в месяц.
По теме - сайт-визитка сегодня... А оно того стоит? Когда-то соц.сети прочно отобрали эту нишу у бесплатных хостингов. И на то были (о остаются!) причины. И красивый адрес - одна из них. Очень часто не надо даже писать URL, достаточно ника и значка соцсети.
В разговорах со своими коллегами я очень часто слышал фразу «алгоритмы программистам не нужны», «алгоритмы никогда не используются в работе» и т.п.
Т.е. коллеги решают поставленные им вопросы, тем же методом, что и обезьяны пишут "войну и мир"? Вообще, пока решение любой задачи алгоритмизируется. И без этого никак. Ну, может быть, вышеназванным методом... Но это маловероятно...
Другое дело, что для решения конкретной задачи не нужно все множество алгоритмов, а самые востребованные алгоритмы давно существуют в виде библиотек.
Отсюда главный вопрос - а что спрашивает данная статья? Должен ли программист знать ВСЕ МНОЖЕСТВО АЛГОРИТМОВ, созданных до него и им самим? Очевидно нет. В отдельных случаях надо знать ГДЕ посмотреть тот или иной алгоритм. Должен ли программист уметь составлять и реализовывать алгоритмы? Очевидно да, ибо это и есть его основная работа. Должен ли программист использовать алгоритмы из библиотек, вместо создания своих собственных - это реально вопрос. Но он точно не имеет однозначного ответа, и действительно тут все зависит только от задачи. В общем случае, если МОЖНО использовать готовое, то НУЖНО использовать готовое. В остальных случаях ПРИДЕТСЯ делать самому.
Ну да. Лучший инструмент - это тот, которым ты сегодня можешь делать продукт.
А те, кто только начинает вольны выбрать любой из представленных инструментов. В конце-концов всегда "фотографирует фотограф, а не фотоаппарат". И вообще, "Пусть расцветают сто цветов, пусть соперничают сто школ" (с)
Вообще-то я комментировал не статью. У меня к ней нет никаких претензий. Я отвечал на откровенно провокационный комментарий. И даже процитировал ключевую его часть.
P.S.
И еще - я вместо "противники", писал "молодцы". Что уже само по себе характеризует отношение а оппоненту. Разве нет?
Слушайте, ситуация с Rust напоминает ситуацию с ЛГБТ-повесточкой.
Я совершенно ничего не имею против тех, кто пишет быстрый, надежный и безопасный код на RUST. Молодцы. Но я просто бешусь, когда они начинают рассказывать мне как я должен писать код. Вот и все.
Это ссылка на Матрицу с "ложки нет, Нео". Можете найти в поисковике.
Я не настолько стар, чтоб не помнить первую часть матрицы. И да, я вполне понял отсылку.
По остальному... Административные методы работают. С родителями наверное нет, а вот с наемными работниками гарантировано да. Разумные административные методы (типа использования системы контроля версий и поддержания порядка в репозитарии) работаю очень эффективно. Ибо очень быстро приходит осознание полезности этой "административщины".
При всем при этом у меня нет особого пиетита к старшему поколению. Я видел разных. По моим мироощущениям из нынешней молодежи процент тех, с кем в зрелом возрасте будет приятно работать, примерно такой же. Мне кажется, что это не образовательное и даже не воспитание - это, видимо, биология. Должна быть "серая масса посередине" и должны быть примеры вверх и вниз. Почти по Гаусу. Впрочем, это частное мнение. Я не готов за него сильно бороться. А вот то, что на моем жизненном пути пути попадались те самые пики вверх - это факт. Учится у них было очень здорово. Даже если их сфера деятельности была довольно далека от моих профессиональных интересов.
Что до python... Нет, спасибо. Я отделаюсь старой шуткой, про то что язык, работоспособность которого задисит от настроек редактора - это очень своеобразный язык. Наверное, когда-нить меня меня заставят административными методами его изучить. Для написания тестов или чего-то подобного. Я развлекался проходя MIT'овский курс по программированию - а там именно python в основе. Ничего, справлялся. По сути - знаешь один язык - знаешь все (Кто скажет "Пролог" - тому бан сразу. Шутка, в которой только доля шутки - а остальное чистая правда). Что до "смешных примеров" - ну так их на любом языке хватает. Они ведь нужны для того, чтоб отделить специалистов по языку, от тех кто таковым только называется. Их не используют в реальных проектах (обычно?).
И уж поверьте - python был назван вполне осознанно. Во первых его ниша уже понятна, язык достаточно зрелый и не так давно прошедший через крупную "работу над ошибками" при переходе со второй на третью версию. В мире встраиваемых систем есть куда более резонансные темы...
Предлагаю завязывать. Кажется мы не противоречим друг другу.
"Узок круг этих революционеров. Страшно далеки они от народа" (c) В. И. Ленин.
QNX (тоже сильно сложно, но все же POSIX система). Solaris (аналогично - условно POSIX) до сих пор актуальна. Похороненная и живущая только в комментариях на LORе BSD (туда же) основа для Playstion. Ах да, еще macOs корнями упирается в нее же. И это только то, что на слуху и вспоминается на счет раз.
У Linux есть GPL и надзорные органы, которые не очень эффективно, но следят за ее соблюдением. Потому про Linux знают. Можно долго спорить, но "вирусная лицензия" GPL сильно мешает вашему же "могут ... все нужные linux specific APIs реализовать". Тут дело не в гордости. Обратный процесс тоже не очень идет. ZFS портируется с трудом. И да, опять все упирается в "гордости только чуть поубавить". Хотя в ту же BSD давно забрали.
Безусловно, основной прогресс в Linux. Причем прогресс настолько огромный, что уже начинает попахивать цепной реакцией и не очень понятно найдется ли на нее контролирующий стержень. Впрочем, это уже тема отдельного разговора. И я не хочу его начинать.
Если заранее известно про ограничение в 30 км/час зачем покупать спорткар? Если есть задача поставить мировой рекорд скорости, то конейнеровоз не выглядит подходящим решением.
Уникальная задача всегда имеет уникальное решение. А типовое решение всегда неудобный ни для кого компромисс. Главное искусство инженера ровно в том, что бы не путать эти сущности.
Смело, модно, молодежно.
Вообще говоря, posix с самого начала был "чемоданом без ручки". Примерно как знаменитый автомат Калашникова. Каждому конкретному бойцу он неудобен - масса, габариты, кучность, убойная сила.... Но для каждого рода войск и прочих неармейских подразделений своя модификация. При сохранении базовых принципов и взаимозаменяемости основных частей.
В этом смысле Linux, как альтернатива Posix ничего кроме улыбки не вызывает. Posix не запрещает clone() и прочие так любые вашему сердцу моменты. А если единственная целевая аудитория это Linux - ну и славненько.
Спасибо. Хороший аргумент.
Давайте так - каждое из утверждений имеет свои "за" и свои "против". В общем случае хочется думать, что если обозначенные проблемы реально являются проблемами они будут решены. Пусть и не в рамках языка С, который однажды окажется в учебниках по истории IT и редко где в реальной жизни.
Да, именно тут и есть замкнутый круг. Я могу рассказывать на работе молодому поколению. Как правило в режиме ответов на вопрос "что это было?", "а почему так нельзя?" или "а что так можно было"? Тогда появляются структурные и функциональные схемы железок, тогда появляются тайминги и прочие радости нашего уровня. Я честно пытался хоть из чего-то похожего сделать статью. Получается или слишком узко и нишево, или очередной пример такого вот варианта.
Ну или да... Ржут надо мной коллеги-схемотехники. Говорят ты за столько лет уже лекцию "радиоэлектроника для программистов" можешь снимать и на youutube выкладывать. Она и начинающим схемотехникам полезной окажется. За три поколения воспитанников отточил... Может правда как-нить заняться... Тогда может быть текстовая версия и здесь появится. Но пока есть интересная работа и тупо не до того... И это, пожалуй, самое главное.
Вообще получается парадоксальная ситуация - есть потребность в специалистах, но никто не знает как именно их готовить. Ибо инструмент один, а навык его использования оттачивается только в процессе работы. Я даже не знаю с чем бы сравнить... Ну, возможно, MIDI-клавиатура (синтезатор) в музыкальной студии против концертного рояля в консерватории. Т.е. инструмент один, а подход (и, безусловно, результат) разный. При чем и тот и другой результат востребованы. И принципиально нет каких-то серьезных ограничений, по которым пианист-виртуоз не смог бы записать на синтезаторе партии всех инструментов, или музыкант-клавишник современной популярной группы не смог бы исполнить условного Моцарта в условной консерватории, но... Эти миру сосуществуют рядом практически не соприкасаясь. Лишь изредка случается миграция в ту или иную сторону.
Похоже что пока так и останется. Меня на работе учили, я учу и мои последователи учить будут. Может оно и правильно. Ну а здесь будем ловить минусы от тех, кто идет параллельным путем.
На этом уровне как раз и формируется POSIX. Собственно здесь же он и начинает использоваться. В частности и для абстракций высшего уровня. И не только для самого языка С.
Что же до PostgreSQL или Nginx, то.... Может быть Legacy, а может быть разумный выбор инструмента для оптимального решения конкретной задачи.
Все меняется. Кто сейчас помнит самый популярный некогда почтовик sendmail? Уж даже не спрашиваю кто им пользуется... Так что когда становится реально надо, legacy переписывается.
Я вас категорически приветствую!
Да, черт возьми. Собственно по этой причине я и открыл эту ветку комментариев. С наивной надеждой хоть что-то поменять. Только вот... Конструктивный диалог получается разве что со старыми знакомыми. Понятно, что определение "канонический вариант" оно лукаво и не описывает суть проблемы. Но я не знаю как переформулировать более грамотно.
Радует, что понимание того, что язык С разный для разных задач есть не только у меня. Обидно, что нас крайне мало.
Так, собственно, отсюда и вопрос... Дело ведь в том, что язык С изначально пытался занять очень много стульев сразу и претендовал на роль панацеи. Мы не будем тыкать в современные языки, которые ведут себя ровно так же - это проходит со временем. Вот и С довольно быстро разделился.
"Кроссплатформенный ассемблер с элементами структурного синтаксиса" (с) - это современный язык С. Все остальные его реинкарнации потихоньку сходят на нет, уступая место более удобным инструментам. И POSIX в таком варианте наше все. А это read/write, а еще atoi/atof и парные им ftoa/ftol.
"Переносимый между платформами язык С" - это безусловно K&R. В таком варианте безусловно printf/scanf, с соответствующими слоями абстракции. Ну и понятно, что в конце-концов именно "Переносимы С" обрел потомка виде С++ и сильно сдал свои позиции.
Вот отсюда и вопрос. Правда ли, что K&R с их "переносимым С" стоит сегодня рассматривать как канонический вариант использования языка. Да, безусловно, если еще комплект system-utils, sed, find, gawk и прочего прикладного софта нижнего уровня, который написан на таком С. Но все же, современный С это сильно больше язык загрузчиков, ядер операционных систем и драйверов. Другими словами тот самый "кроссплатформенный ассемблер". Или это у меня профдеформация и на самом деле все не так?
Я не спорю с метрами. Я спрашиваю мнение общественности. Особенно той ее части, что работает преимущественно с языком С и спускается к ассемблеру по мере необходимости.
Тем более, что это далеко не идеал, если копнуть поглубже. Например const перед char в общем случае был бы весьма уместен.
Все хорошо. И в целом не новость. Едиственный вопрос, который меня всегда слегка заботит, это почему printf? Разве канонический HelloWorld на C не должен быть таким
P.S.
И не надо мне говорить, что результат, возвращаемый write в целом надо бы проверять. В исходном варианте возвращаемое printf тоже игнорируется.
Ух! Как концом 90-ых пахнуло.... DECT, связь на производстве.... Siemens, Gigaset...
Только вот что ж так мало-то? Как автоматизировали регистрацию трубок? Как связывали между собой базы? Как добивались бесшовного роуминга по всей территории склада? И добились ли вообще? А если добились то для всех ли абонентов? Как боролись с "горячими точками" в плане количества соединений на единицу площади?
В конце 90-ых это было возможно только с очень продвинутыми ISDN станциями, которых почти нигде не было, и которые всеми силами пытались создать сами (довольно успешно, к слову). Правда тогда DECT очень быстро вышел из употребления для этих целей. GSM позволил не строить собственную сеть, а пользоваться операторской. При этом накрывая достаточные площади.
Вообще, DECT очень интересная система. Да, ее знают (знали?) в основном по домашним трубкам. Но вообще-то французский армейский комплекс Felin имел (имеет?) систему внутренний связи как раз на базе DECT. В целом, это фактически GSM в миниатюре. Она именно так и задумывалась, но... В силу ряда причин скатилась к простеньким домашним трубкам.
Я правильно понимаю, что это для юридических лиц? Т.е. сайт-визитка и личный бренд из статьи в лучшем случае для ИП?
Слушайте, а научите меня купить домен за 2-4 бакса в год, так чтоб его можно было к VPS прицепить. Только так, чтоб домен реально мой был, а не "премиум" от dyndns'а - который элементарно завтра закроется и с концами.
Я не знаток таких вещей, но как-то попытался и дальше начинается - домен пожалуйста, и ценник примерно такой, но сразу обязательно резервный DNS сервер, панель управления и прочее, прочее, прочее. По итогу не 2, а хорошо если 50.
"За доллар в месяц вложение в личный бренд и технологическую независимость окупится многократно." - только без собственного доменного имени независимость будет далеко не полной, а с ним будет далеко не доллар в месяц.
По теме - сайт-визитка сегодня... А оно того стоит? Когда-то соц.сети прочно отобрали эту нишу у бесплатных хостингов. И на то были (о остаются!) причины. И красивый адрес - одна из них. Очень часто не надо даже писать URL, достаточно ника и значка соцсети.
Т.е. коллеги решают поставленные им вопросы, тем же методом, что и обезьяны пишут "войну и мир"? Вообще, пока решение любой задачи алгоритмизируется. И без этого никак. Ну, может быть, вышеназванным методом... Но это маловероятно...
Другое дело, что для решения конкретной задачи не нужно все множество алгоритмов, а самые востребованные алгоритмы давно существуют в виде библиотек.
Отсюда главный вопрос - а что спрашивает данная статья? Должен ли программист знать ВСЕ МНОЖЕСТВО АЛГОРИТМОВ, созданных до него и им самим? Очевидно нет. В отдельных случаях надо знать ГДЕ посмотреть тот или иной алгоритм. Должен ли программист уметь составлять и реализовывать алгоритмы? Очевидно да, ибо это и есть его основная работа. Должен ли программист использовать алгоритмы из библиотек, вместо создания своих собственных - это реально вопрос. Но он точно не имеет однозначного ответа, и действительно тут все зависит только от задачи. В общем случае, если МОЖНО использовать готовое, то НУЖНО использовать готовое. В остальных случаях ПРИДЕТСЯ делать самому.
Ну да. Лучший инструмент - это тот, которым ты сегодня можешь делать продукт.
А те, кто только начинает вольны выбрать любой из представленных инструментов. В конце-концов всегда "фотографирует фотограф, а не фотоаппарат". И вообще, "Пусть расцветают сто цветов, пусть соперничают сто школ" (с)
Ну да. Я ведь ровно о том же.
Вообще-то я комментировал не статью. У меня к ней нет никаких претензий. Я отвечал на откровенно провокационный комментарий. И даже процитировал ключевую его часть.
P.S.
И еще - я вместо "противники", писал "молодцы". Что уже само по себе характеризует отношение а оппоненту. Разве нет?
Слушайте, ситуация с Rust напоминает ситуацию с ЛГБТ-повесточкой.
Я совершенно ничего не имею против тех, кто пишет быстрый, надежный и безопасный код на RUST. Молодцы. Но я просто бешусь, когда они начинают рассказывать мне как я должен писать код. Вот и все.
Я не настолько стар, чтоб не помнить первую часть матрицы. И да, я вполне понял отсылку.
По остальному... Административные методы работают. С родителями наверное нет, а вот с наемными работниками гарантировано да. Разумные административные методы (типа использования системы контроля версий и поддержания порядка в репозитарии) работаю очень эффективно. Ибо очень быстро приходит осознание полезности этой "административщины".
При всем при этом у меня нет особого пиетита к старшему поколению. Я видел разных. По моим мироощущениям из нынешней молодежи процент тех, с кем в зрелом возрасте будет приятно работать, примерно такой же. Мне кажется, что это не образовательное и даже не воспитание - это, видимо, биология. Должна быть "серая масса посередине" и должны быть примеры вверх и вниз. Почти по Гаусу. Впрочем, это частное мнение. Я не готов за него сильно бороться. А вот то, что на моем жизненном пути пути попадались те самые пики вверх - это факт. Учится у них было очень здорово. Даже если их сфера деятельности была довольно далека от моих профессиональных интересов.
Что до python... Нет, спасибо. Я отделаюсь старой шуткой, про то что язык, работоспособность которого задисит от настроек редактора - это очень своеобразный язык. Наверное, когда-нить меня меня заставят административными методами его изучить. Для написания тестов или чего-то подобного. Я развлекался проходя MIT'овский курс по программированию - а там именно python в основе. Ничего, справлялся. По сути - знаешь один язык - знаешь все (Кто скажет "Пролог" - тому бан сразу. Шутка, в которой только доля шутки - а остальное чистая правда). Что до "смешных примеров" - ну так их на любом языке хватает. Они ведь нужны для того, чтоб отделить специалистов по языку, от тех кто таковым только называется. Их не используют в реальных проектах (обычно?).
И уж поверьте - python был назван вполне осознанно. Во первых его ниша уже понятна, язык достаточно зрелый и не так давно прошедший через крупную "работу над ошибками" при переходе со второй на третью версию. В мире встраиваемых систем есть куда более резонансные темы...
Предлагаю завязывать. Кажется мы не противоречим друг другу.