Давайте так - каждое из утверждений имеет свои "за" и свои "против". В общем случае хочется думать, что если обозначенные проблемы реально являются проблемами они будут решены. Пусть и не в рамках языка С, который однажды окажется в учебниках по истории 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 был назван вполне осознанно. Во первых его ниша уже понятна, язык достаточно зрелый и не так давно прошедший через крупную "работу над ошибками" при переходе со второй на третью версию. В мире встраиваемых систем есть куда более резонансные темы...
Предлагаю завязывать. Кажется мы не противоречим друг другу.
Я путаю и увожу разговор в сторону? А еще тыкаю носом в ошибки? Интересно...
У многих людей из старшего поколения вообще нет культуры работы с VCS. И вот это приходится ломать через колено...
Так а я вроде бы нигде и не писал что любой представитель старшего поколения "великий мастер" просто по определению. Как всегда - в любом срезе общества хватает и мастеров и самозванцев. И старшее поколение в этом плане ничем особенно не отличается. Хотя... Возможно с возрастом оттачиваются не только положительные.
Мне пришлось примерно 20 лет назад заставить отца начать использовать VCS (выбрали git)...
Боюсь 20 лет назад git только начинал свое победное шествие. В тот момент куда как более разумным выбором был бы CVS или Subversion. И да, Internet тогда не был настолько удобным, быстрым и доступным чтобы этим активно пользоваться.
За 20 лет многое изменилось. Человек, который работает в разработке последние несколько десятков лет, сегодня наверняка не будет отказываться от GIT.
Хотя... Я так и не добрался до того же python'а. Ну как не добрался - а понимаю написанное и могу пользоваться справочной системой, но писать сам... Увы. Мой мозг думает на другом языке. И тесты пишет на языке разработки. Увы. А нейропластичность для защиты от деменции я предпочту повышать другими методами. Освоив пианино или заведя аквариум.
Как только человек вообще осознал, что "можно есть не только руками", то есть существуют процесс с использованием VCS...
Да, пожалуй тут я по большей части соглашусь. И, пожалуй, тут есть возрастной момент. "Есть многое на свете, друг Горацио, что и не снилось нашим мудрецам" (с). С возрастом действительно начинает срабатывать фокусировка на том, что реально интересно и важно, а желание "объять необъятное" и стать "специалистом по всем вопросам" уходит. Может не у всех, но у многих. Да, местами это выливается в такие вот казусы с репозитарием и флешкой. И да, это вполне решается административными методами. Ну будет git репозитарий продублирован архивом на флешке - это, конечно, криминал-криминал...
Главное - понимание, что можно есть ложкой, что "ложка есть".
Ну так казуистика же. В чистом виде.
А еще есть можно есть вилкой и "вилка есть".
Давайте не путать человека с дегенеративнми заболеваниями нервной системы и активного разработчика. Они отличаются именно упертостью. Если я на собеседовании вижу, что "владение python'ом" важнее знания предметной области - я сам уйду. А за дверью пожму плечами.
Первый барьер разработали как раз к моменту закупки партии таковых заказчиком. Заявились с первым прототипом к заказчику гордые и радостные. И услышали такой вопрос:
где сертификат искрозащиты?
А эта цитата из вашей статьи, доказывает что некоторые могут вместо ложки обходиться вилкой или палочками, а отдельные товарищи вообще руками (плов) есть, но при этом быть настоящим специалистом и знать основополагающие нормативные документы в своей отрасли.
Главное понимать что важно для конкретно взятого заказчика.
Ну так и я говорю что вопрос не ко мне, а скорее к вам. Если ваш процесс разработки четко и бюрократически описан, то...
Либо это не разработка, а "напиливание фич и устранение багов" в давно законченном изделии. Это все же несколько другое. Я видел такие организации - там вполне можно работать. И даже платят. Но... Просто не мое. По мне разработка - это создание чего-то, что было до этого в лучшем случае в виде концепта (и то не всегда). ТЗ всегда выглядит как принципиально нереализуемая современными средствами задача, за которую даже браться страшно. Но которая шаг за шагом становится реальностью. И ее принципиально невозможно сделать одному. Времена ДаВинчи и Ломоносова давно прошли, и нужны люди, которые смогут свернуть эту гору. А уж будут они уже знать git или pyton или гореть желанием их изучить в ближайшее время - дело десятое. Это всего лишь один из вспомогательных навыков.
Либо, как бы это помягче... выстроена жесткая вертикаль власти, когда есть Д'Артаньян и есть все остальные [далее самоцензура, характеризующая не очень грамотных сотрудников]. Вот такое встречается часто... И да, тут "без знания git, хотя бы (а лучше строго) на уровне Д'Артаньяна" делать совершенно нечего. Мне искренне жаль людей, которые в таких местах работают. Впрочем, возможно просто складывается удачная пара из садиста и мазохистов... А может я чего-то не понимаю.
Руководите, нанимайте того, кого считаете нужным - в конце концов вам поручено и ответственность за результат только на вас. Я (пока?) не занимаюсь наймом. Я обычный инженер (надеюсь, правда, довольно грамотный).
Спасибо. Хороший аргумент.
Давайте так - каждое из утверждений имеет свои "за" и свои "против". В общем случае хочется думать, что если обозначенные проблемы реально являются проблемами они будут решены. Пусть и не в рамках языка С, который однажды окажется в учебниках по истории 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 был назван вполне осознанно. Во первых его ниша уже понятна, язык достаточно зрелый и не так давно прошедший через крупную "работу над ошибками" при переходе со второй на третью версию. В мире встраиваемых систем есть куда более резонансные темы...
Предлагаю завязывать. Кажется мы не противоречим друг другу.
Я путаю и увожу разговор в сторону? А еще тыкаю носом в ошибки? Интересно...
Так а я вроде бы нигде и не писал что любой представитель старшего поколения "великий мастер" просто по определению. Как всегда - в любом срезе общества хватает и мастеров и самозванцев. И старшее поколение в этом плане ничем особенно не отличается. Хотя... Возможно с возрастом оттачиваются не только положительные.
Боюсь 20 лет назад git только начинал свое победное шествие. В тот момент куда как более разумным выбором был бы CVS или Subversion. И да, Internet тогда не был настолько удобным, быстрым и доступным чтобы этим активно пользоваться.
За 20 лет многое изменилось. Человек, который работает в разработке последние несколько десятков лет, сегодня наверняка не будет отказываться от GIT.
Хотя... Я так и не добрался до того же python'а. Ну как не добрался - а понимаю написанное и могу пользоваться справочной системой, но писать сам... Увы. Мой мозг думает на другом языке. И тесты пишет на языке разработки. Увы. А нейропластичность для защиты от деменции я предпочту повышать другими методами. Освоив пианино или заведя аквариум.
Да, пожалуй тут я по большей части соглашусь. И, пожалуй, тут есть возрастной момент. "Есть многое на свете, друг Горацио, что и не снилось нашим мудрецам" (с). С возрастом действительно начинает срабатывать фокусировка на том, что реально интересно и важно, а желание "объять необъятное" и стать "специалистом по всем вопросам" уходит. Может не у всех, но у многих. Да, местами это выливается в такие вот казусы с репозитарием и флешкой. И да, это вполне решается административными методами. Ну будет git репозитарий продублирован архивом на флешке - это, конечно, криминал-криминал...
Ну так казуистика же. В чистом виде.
А еще есть можно есть вилкой и "вилка есть".
Давайте не путать человека с дегенеративнми заболеваниями нервной системы и активного разработчика. Они отличаются именно упертостью. Если я на собеседовании вижу, что "владение python'ом" важнее знания предметной области - я сам уйду. А за дверью пожму плечами.
А эта цитата из вашей статьи, доказывает что некоторые могут вместо ложки обходиться вилкой или палочками, а отдельные товарищи вообще руками (плов) есть, но при этом быть настоящим специалистом и знать основополагающие нормативные документы в своей отрасли.
Главное понимать что важно для конкретно взятого заказчика.
Ну так и я говорю что вопрос не ко мне, а скорее к вам. Если ваш процесс разработки четко и бюрократически описан, то...
Либо это не разработка, а "напиливание фич и устранение багов" в давно законченном изделии. Это все же несколько другое. Я видел такие организации - там вполне можно работать. И даже платят. Но... Просто не мое. По мне разработка - это создание чего-то, что было до этого в лучшем случае в виде концепта (и то не всегда). ТЗ всегда выглядит как принципиально нереализуемая современными средствами задача, за которую даже браться страшно. Но которая шаг за шагом становится реальностью. И ее принципиально невозможно сделать одному. Времена ДаВинчи и Ломоносова давно прошли, и нужны люди, которые смогут свернуть эту гору. А уж будут они уже знать git или pyton или гореть желанием их изучить в ближайшее время - дело десятое. Это всего лишь один из вспомогательных навыков.
Либо, как бы это помягче... выстроена жесткая вертикаль власти, когда есть Д'Артаньян и есть все остальные [далее самоцензура, характеризующая не очень грамотных сотрудников]. Вот такое встречается часто... И да, тут "без знания git, хотя бы (а лучше строго) на уровне Д'Артаньяна" делать совершенно нечего. Мне искренне жаль людей, которые в таких местах работают. Впрочем, возможно просто складывается удачная пара из садиста и мазохистов... А может я чего-то не понимаю.
Руководите, нанимайте того, кого считаете нужным - в конце концов вам поручено и ответственность за результат только на вас. Я (пока?) не занимаюсь наймом. Я обычный инженер (надеюсь, правда, довольно грамотный).