Хроники смерти Ruby: круги на воде (2/6)
Посредественная статья от "учителя, автора книг, С++-разработчика, AWS-консультанта" (см. прыдудщие посты), опубликованная в довольно крупном онлайн-издании, породила круги на воде. Люди начали задавать вопросы, ставить промблемы.
"Рубисты", конечно, в основном продолжали заниматься своим делом и вообще были не в курсе происходящего. Я сам в 2014 взялся за очередной проект, стейкхолдеры которого (не будучи программистами) выбрали Rails за его рентабельность для бизнеса. И так, как-то по инерции, переходя раз в год-два на очередной новый проект с очередным рутинным повышением зарплаты, узнал о том, что Ruby умер, году в 2019-м. Узнал случайно, поскольку тема начала подниматься в кругах потенциальных клиентов Rails-курса, где я преподаю.
В инфополе, тем временем, в 2014-2015 году кто-то лениво отпинывался от статьи Джеффа, мягко намекая, что ставить в один ряд Perl, Delphi, VB.NET и Ruby это несколько перебор, в независимости от популярности последнего.
Кто-то закинул удочку прямо в мейлинг лист по Ruby, в обсуждение довольно мелкого, но всё же существенного рутинного технического вопроса (введения frozen string literals по умолчанию): один из разработчиков риторически спросил, не умирает ли Ruby потому, что другой разработчик настаивал на изменениях(!) языка в сторону упрощения(!) его применения конечными пользователями. Логика абсурдная, но вброс был сделан. "Внутренний круг разработчиков Ruby обсуждает, не умирает ли Ruby".
Кто-то начал использовать заданный тренд демагогии для оправдания недостатков конкурирующих платформ. Очередной PHP-разработчик пишет, что "преимущества Ruby пропали с появлением Laravel". Оцените накал пафоса: Laravel – это попытка прямо скопировать успех Rails на PHP. Попытка, в определённой степени, удачная, поскольку за PHP стоят бюджеты инертного Facebook-а, в своё время прогадавшего с выбором языка, да так и тянущего за собой грузило – бюджеты, гарантирующие определённую популярность. Проблема такой попытки в следующем: разработчик Ruby старался сделать язык, удобный для людей; а разработчик PHP слепил (по собственному его признанию) тяп-ляп, и когда ему указывают на большое количество накопившихся недоработок, то он с раздражением отвечает, что исправлять ничего не собирается, всё и так хорошо, поскольку язык вон видите какой популярный. Необразованный плагиатор и имитатор через губу бросил оригинальному автору замечание о том, что у последнего "уже нет преимуществ".
Адепты серверной разработки на Javascript (появление node.js во многом воспринималась как первоапрельская шутка, сделанная в неправильное время года – но ничего, сейчас попривыкли уже) зашли с другой стороны. Пользуясь своим профессиональным опытом, они сделали следующее предсказание: т.к. веб-фреймворки постоянно рождаются и умирают, то и Rails скоро умрёт. Проблема в том, что предсказание актуально для мира Javascript, но не для Rails.
Между Rails 3-й версии (2010) и 6-й (2019) различий в базовой функциональности так мало (с точки зрения пользователя – "внутренности" минимум дважды, конечно, переписали практически полностью), что переучиться можно, наверное, за пару дней (хотя, конечно, кое-что добавили, что придётся изучать дополнительно). В тот же временной период в JS изменился сам язык до почти полной неузнаваемости, а изменения первой цифры версий фреймворков (Angular 1 -> 2, React 3 -> 17 и др.) сопровождается, фактически, полным пересмотром всех основ – по сути созданием нового фреймворка. Тот критик несколько раз за прошедшее время становился полностью неактуальными и должен был начинать, фактически, с нуля (если смог).
Rails, напротив, это очень стабильная работа. Которая будет актуальна столько времени, сколько будет актуален современный интернет (пока все не перейдут, например, в VR, или не осядут по крупнейшим соцсетям с закрытием всех независимых сайтов).
#programming #ruby
Посредественная статья от "учителя, автора книг, С++-разработчика, AWS-консультанта" (см. прыдудщие посты), опубликованная в довольно крупном онлайн-издании, породила круги на воде. Люди начали задавать вопросы, ставить промблемы.
"Рубисты", конечно, в основном продолжали заниматься своим делом и вообще были не в курсе происходящего. Я сам в 2014 взялся за очередной проект, стейкхолдеры которого (не будучи программистами) выбрали Rails за его рентабельность для бизнеса. И так, как-то по инерции, переходя раз в год-два на очередной новый проект с очередным рутинным повышением зарплаты, узнал о том, что Ruby умер, году в 2019-м. Узнал случайно, поскольку тема начала подниматься в кругах потенциальных клиентов Rails-курса, где я преподаю.
В инфополе, тем временем, в 2014-2015 году кто-то лениво отпинывался от статьи Джеффа, мягко намекая, что ставить в один ряд Perl, Delphi, VB.NET и Ruby это несколько перебор, в независимости от популярности последнего.
Кто-то закинул удочку прямо в мейлинг лист по Ruby, в обсуждение довольно мелкого, но всё же существенного рутинного технического вопроса (введения frozen string literals по умолчанию): один из разработчиков риторически спросил, не умирает ли Ruby потому, что другой разработчик настаивал на изменениях(!) языка в сторону упрощения(!) его применения конечными пользователями. Логика абсурдная, но вброс был сделан. "Внутренний круг разработчиков Ruby обсуждает, не умирает ли Ruby".
Кто-то начал использовать заданный тренд демагогии для оправдания недостатков конкурирующих платформ. Очередной PHP-разработчик пишет, что "преимущества Ruby пропали с появлением Laravel". Оцените накал пафоса: Laravel – это попытка прямо скопировать успех Rails на PHP. Попытка, в определённой степени, удачная, поскольку за PHP стоят бюджеты инертного Facebook-а, в своё время прогадавшего с выбором языка, да так и тянущего за собой грузило – бюджеты, гарантирующие определённую популярность. Проблема такой попытки в следующем: разработчик Ruby старался сделать язык, удобный для людей; а разработчик PHP слепил (по собственному его признанию) тяп-ляп, и когда ему указывают на большое количество накопившихся недоработок, то он с раздражением отвечает, что исправлять ничего не собирается, всё и так хорошо, поскольку язык вон видите какой популярный. Необразованный плагиатор и имитатор через губу бросил оригинальному автору замечание о том, что у последнего "уже нет преимуществ".
Адепты серверной разработки на Javascript (появление node.js во многом воспринималась как первоапрельская шутка, сделанная в неправильное время года – но ничего, сейчас попривыкли уже) зашли с другой стороны. Пользуясь своим профессиональным опытом, они сделали следующее предсказание: т.к. веб-фреймворки постоянно рождаются и умирают, то и Rails скоро умрёт. Проблема в том, что предсказание актуально для мира Javascript, но не для Rails.
Между Rails 3-й версии (2010) и 6-й (2019) различий в базовой функциональности так мало (с точки зрения пользователя – "внутренности" минимум дважды, конечно, переписали практически полностью), что переучиться можно, наверное, за пару дней (хотя, конечно, кое-что добавили, что придётся изучать дополнительно). В тот же временной период в JS изменился сам язык до почти полной неузнаваемости, а изменения первой цифры версий фреймворков (Angular 1 -> 2, React 3 -> 17 и др.) сопровождается, фактически, полным пересмотром всех основ – по сути созданием нового фреймворка. Тот критик несколько раз за прошедшее время становился полностью неактуальными и должен был начинать, фактически, с нуля (если смог).
Rails, напротив, это очень стабильная работа. Которая будет актуальна столько времени, сколько будет актуален современный интернет (пока все не перейдут, например, в VR, или не осядут по крупнейшим соцсетям с закрытием всех независимых сайтов).
#programming #ruby
Хроники смерти Ruby: старички на марше (3/6)
Переходим к 2016-2017 годам.
Очередной "консультант по облакам", рекламирующий себя на Quora как (не преувеличиваю, реально, так и пишет в своём профиле) "Задаватель Тяжёлых Вопросов" (ну, то есть, человек ставит промблемы-с), растекается мыслью по древу в 2016 году: Ruby плохой язык, так как обслуживает нужды Rails, а больше нигде и не используется.
Ну, во-первых, используется ещё в Devops.
Во-вторых, уважаемый, вы тему не меняйте. Речь шла про веб-разработку. С другими нишами компетентные люди разберутся, если будет время и деньги: не будите лихо. С этой уже разобрались так, что до сих пор все успокоиться не могут, так и норовят всё метку смерти налепить. Со всех сторон уже облепили, а языку хоть бы хны.
По пунктам отвечать на очередное сравнение Ruby с VB и COBOL (последний разработан в 1959 году, ещё до Алгола, положившего начало всем современным процедурным языкам, и сейчас применяется в устаревшем на полвека софте американских банков), впрочем, не буду. Мне кажется, аватар очередного эксперта по веб-разработке говорит сам за себя: то есть понятно, что человек может порассуждать предметно о COBOL-е, но вот сам факт, что он его вспомнил и привёл в аргументе, уже является в полной мере самораскрывающим. "Дедушке пора на пенсию, заговаривается".
Ну а дальше пошла плясать губерния. Основной тон плясок примерно такой:
2014 – "Ruby умер"
2016 – "Ruby умирает и вот-вот умрёт"
2019 – "Ruby ещё держится, но вот-вот начнёт умирать"
К пляскам присоединились самые широкие массы трудящихся.
Евангелисты Go (языка, который разработала и поддерживает Google, крупнейшая IT-корпорация Земли) не посчитали выше своего достоинства присоединиться к общей демагогии. Мол, "руби умер, го писать на го". Предлагается писать на сравнительно неплохой вариации на тему языка Pascal (разработан в 1970), в которой разработчикам не удалось (в основном по организационно-политическим, а не техническим причинам) заимствовать многие полезные фичи из последователя паскаля, языка Oberon (разработан в 1986).
В чём замысел Go? Go – это язык, созданный стариками для студентов. Причём стариками, которые, в сущности, не любят студентов; мало того что не понимают их (это не грех, если разница в возрасте большая), но и не хотят понять; считают их чрезмерно амбиционзными дураками, которых надо приземлить. А Ruby – это язык, созданный взрослыми людьми для взрослых людей, чтобы дать им свободу и работающий инструмент самовыражения.
Не трудно заметить, что для того, чтобы полюбить Go-разработку (по принуждению и за хорошие деньги можно писать на чём угодно), мало быть студентом, надо ещё иметь низкую самооценку.
К пляскам на короткое время присоединяются сторонники Swift. Языка, разработанного в Apple для того, чтобы дать альтернативу к тому моменту уже совсем позорной неэстетичности Objective C. В сущности, Apple, выражаясь просторечно, прокинула пользователей Ruby. Малоизвестный факт: в Apple разрабатывалась, до какого-то момента, своя версия интерпретатора Ruby (MacRuby – 2007-2012), с компиляцией в низкоуровневый байткод LLVM, за счёт чего достагалсь производительность, сравнимая с компилируемыми языками. В конечном итоге Apple решила, в своей манере, не поддерживать общественный проект, а сделать свой уникальный продукт, выпустив Swift. Впрочем, macOS/iOS разработка это свой собственный мир, с веб-разработкой практически не пересекающийся, поэтому в данном разборе уделять ему внимания больше не будем. Реинкарнация идеи "компилируемого Ruby для маков" живёт в виде проекта Rubymotion, который пока только пытается нащупать целевую нишу.
Наконец, набирает популярность язык Elixir (2012). Язык создан "рубистом" (действующим членом команды разработки Rails) Хосе Валимом для платформы Erlang. Erlang (появился в 1980-х) – платформа для "старичков", занимающихся разработкой софта для телефонных сетей и коммутаторов, получает второе дыхание и выходит на оперативные просторы, становясь не просто "надёжной" или "зарекомендовавшей себя" технологией, а модной и приятной.
#programming #ruby
Переходим к 2016-2017 годам.
Очередной "консультант по облакам", рекламирующий себя на Quora как (не преувеличиваю, реально, так и пишет в своём профиле) "Задаватель Тяжёлых Вопросов" (ну, то есть, человек ставит промблемы-с), растекается мыслью по древу в 2016 году: Ruby плохой язык, так как обслуживает нужды Rails, а больше нигде и не используется.
Ну, во-первых, используется ещё в Devops.
Во-вторых, уважаемый, вы тему не меняйте. Речь шла про веб-разработку. С другими нишами компетентные люди разберутся, если будет время и деньги: не будите лихо. С этой уже разобрались так, что до сих пор все успокоиться не могут, так и норовят всё метку смерти налепить. Со всех сторон уже облепили, а языку хоть бы хны.
По пунктам отвечать на очередное сравнение Ruby с VB и COBOL (последний разработан в 1959 году, ещё до Алгола, положившего начало всем современным процедурным языкам, и сейчас применяется в устаревшем на полвека софте американских банков), впрочем, не буду. Мне кажется, аватар очередного эксперта по веб-разработке говорит сам за себя: то есть понятно, что человек может порассуждать предметно о COBOL-е, но вот сам факт, что он его вспомнил и привёл в аргументе, уже является в полной мере самораскрывающим. "Дедушке пора на пенсию, заговаривается".
Ну а дальше пошла плясать губерния. Основной тон плясок примерно такой:
2014 – "Ruby умер"
2016 – "Ruby умирает и вот-вот умрёт"
2019 – "Ruby ещё держится, но вот-вот начнёт умирать"
К пляскам присоединились самые широкие массы трудящихся.
Евангелисты Go (языка, который разработала и поддерживает Google, крупнейшая IT-корпорация Земли) не посчитали выше своего достоинства присоединиться к общей демагогии. Мол, "руби умер, го писать на го". Предлагается писать на сравнительно неплохой вариации на тему языка Pascal (разработан в 1970), в которой разработчикам не удалось (в основном по организационно-политическим, а не техническим причинам) заимствовать многие полезные фичи из последователя паскаля, языка Oberon (разработан в 1986).
В чём замысел Go? Go – это язык, созданный стариками для студентов. Причём стариками, которые, в сущности, не любят студентов; мало того что не понимают их (это не грех, если разница в возрасте большая), но и не хотят понять; считают их чрезмерно амбиционзными дураками, которых надо приземлить. А Ruby – это язык, созданный взрослыми людьми для взрослых людей, чтобы дать им свободу и работающий инструмент самовыражения.
Не трудно заметить, что для того, чтобы полюбить Go-разработку (по принуждению и за хорошие деньги можно писать на чём угодно), мало быть студентом, надо ещё иметь низкую самооценку.
К пляскам на короткое время присоединяются сторонники Swift. Языка, разработанного в Apple для того, чтобы дать альтернативу к тому моменту уже совсем позорной неэстетичности Objective C. В сущности, Apple, выражаясь просторечно, прокинула пользователей Ruby. Малоизвестный факт: в Apple разрабатывалась, до какого-то момента, своя версия интерпретатора Ruby (MacRuby – 2007-2012), с компиляцией в низкоуровневый байткод LLVM, за счёт чего достагалсь производительность, сравнимая с компилируемыми языками. В конечном итоге Apple решила, в своей манере, не поддерживать общественный проект, а сделать свой уникальный продукт, выпустив Swift. Впрочем, macOS/iOS разработка это свой собственный мир, с веб-разработкой практически не пересекающийся, поэтому в данном разборе уделять ему внимания больше не будем. Реинкарнация идеи "компилируемого Ruby для маков" живёт в виде проекта Rubymotion, который пока только пытается нащупать целевую нишу.
Наконец, набирает популярность язык Elixir (2012). Язык создан "рубистом" (действующим членом команды разработки Rails) Хосе Валимом для платформы Erlang. Erlang (появился в 1980-х) – платформа для "старичков", занимающихся разработкой софта для телефонных сетей и коммутаторов, получает второе дыхание и выходит на оперативные просторы, становясь не просто "надёжной" или "зарекомендовавшей себя" технологией, а модной и приятной.
#programming #ruby
Хроники смерти Ruby: Ruby и Elixir (4/6)
Elixir, оттолкнувшись от рубишной базы энтузиастов и заимствовав некоторые элементы внешней эстетики языка Ruby, быстро уходит в свободное плавание. Социально активные рубисты, до которых спустя несколько лет наконец начали доходить слухи о скоропостижной кончине любимого языка, начинают давать восторженные отзывы Elixir-у. Пишутся статьи, переходят разработчики, выступают на Ruby-конференциях с обзором новой модной темы. Через пару лет возвращаются обратно на Ruby.
Elixir и Phoenix занимают свою, пока что ещё не до конца устоявшуюся, нишу в мире веб-разработки. Rails – это "через пять лет вырастем до 100 тыс. пользователей". Elixir – это "уже сейчас 1 млн. запросов в секунду". Это мир Discord-а, Whatsapp-а, некоторых подсистем серверов онлайн-игр и прочих распределённых приложений. Ниша пересекается с классическими веб-приложениями, но не сильно.
Мир Elixir, по ряду причин, очень конгруентен миру Ruby. Elixir в использовании гораздо более сложный, чем Ruby (а Phoenix гораздо менее продуктивный в типовых случаях, чем Rails). Сложность окупается кратным ростом возможной производительности с тем же "железом". Из одной экосистемы в другую постоянно идёт взаимопроникновение идей и технологий. Phoenix списывает, творчески перерабатывая под функциональную парадигму (и постепенно в целом радикально переиначивая на свой лад), основную структуру Rails-приложения. Rails списывает экспериментальную и недоработанную идею LiveView (серверных обновлений клиентских событий) у Phoenix, доводит до ума на свой лад и тут же выпускает в production. Phoenix успевает только глазами хлопать. Короче, милые бранятся – только тешатся.
#programming #ruby
Elixir, оттолкнувшись от рубишной базы энтузиастов и заимствовав некоторые элементы внешней эстетики языка Ruby, быстро уходит в свободное плавание. Социально активные рубисты, до которых спустя несколько лет наконец начали доходить слухи о скоропостижной кончине любимого языка, начинают давать восторженные отзывы Elixir-у. Пишутся статьи, переходят разработчики, выступают на Ruby-конференциях с обзором новой модной темы. Через пару лет возвращаются обратно на Ruby.
Elixir и Phoenix занимают свою, пока что ещё не до конца устоявшуюся, нишу в мире веб-разработки. Rails – это "через пять лет вырастем до 100 тыс. пользователей". Elixir – это "уже сейчас 1 млн. запросов в секунду". Это мир Discord-а, Whatsapp-а, некоторых подсистем серверов онлайн-игр и прочих распределённых приложений. Ниша пересекается с классическими веб-приложениями, но не сильно.
Мир Elixir, по ряду причин, очень конгруентен миру Ruby. Elixir в использовании гораздо более сложный, чем Ruby (а Phoenix гораздо менее продуктивный в типовых случаях, чем Rails). Сложность окупается кратным ростом возможной производительности с тем же "железом". Из одной экосистемы в другую постоянно идёт взаимопроникновение идей и технологий. Phoenix списывает, творчески перерабатывая под функциональную парадигму (и постепенно в целом радикально переиначивая на свой лад), основную структуру Rails-приложения. Rails списывает экспериментальную и недоработанную идею LiveView (серверных обновлений клиентских событий) у Phoenix, доводит до ума на свой лад и тут же выпускает в production. Phoenix успевает только глазами хлопать. Короче, милые бранятся – только тешатся.
#programming #ruby
Хроники смерти Ruby: пик популярности (5/6)
К 2017-2018 годам, через 6 лет после даты смерти (2011) и через 3 года после её публичного объявления (2014), Ruby достигает невиданной популярности. До этой поры будучи в общем-то нишевым языком, "себе на уме", инструментом для сравнительно небольшой группы приверженцев (хоть и постоянно растущей), Ruby/Rails становится абсолютным мейнстримом.
Напомню, что создатель Ruby on Rails, Дэвид Хейнмайер Хэнсон, в своей книге "Getting real" (можно перевести как-то вроде "Становясь реалистичным") писал как владелец небольшой компании другим владельцам (и сотрудникам) небольших компаний: ребята, умерьте аппетиты. Не надо мегаломанских целей типа стать фейсбуком. Поставьте скромную цель. Например, миллион баксов в год. Чистыми.
Не надо стремиться к публикациям в больших журналах, типа Wall Street. Занимайтесь маркетингом в своей нише.
Не надо стремиться купить домен из одного словарного слова. Берите любой подходящий, добавьте "app" если надо. Первый домен для приложения компании: basecamphq.com
Спустя годы, конечно, компания-разработчик Rails покупает домен "basecamp.com".
А уже в наше время купила домен "hey.com" (2020) для своего нового email-сервиса (цена не разглашается; из общих соображений, от сотен тысяч до нескольких миллионов долларов).
Про ряд публикаций в Wall Street и выход книги-бестселлера Rework и не говорю.
В компании Basecamp скромно поясняют, мол, к такому успеху не стремились, но к нему пришли.
Следом за успехом материнской компании, получает свои 15 минут славы и разработанный ей (с участием открытого сообщества) фреймворк.
Зарплата Ruby on Rails разработчика выходит на первую строку таблицы зарплат веб-разработчиков.
Ruby заходит одной ногой в топ-10 популярных языков. В последующие годы рекорд не побит: болтается с 10 по 15 место.
Феноменальный успех для нишевого языка, который не поддерживает ни одна всемирная корпорация, и который находился под постоянным коллективным прессингом со стороны агитаторов всех конкурентов.
И вот с этого момента, наконец, можно считать Ruby состоявшимся языком, который хотя бы в теории может начать умирать. По-моему, плато действительно пройдено. Что же, C++ умирает 25 лет. Java умирает 20 лет. .NET умирает 15 лет. Ну и Ruby ещё покочевряжится немножко, как минимум пока нынешние первокурсники не станут шестидесятилетними старичками и не уйдут на пенсию. Не трудно заметить, что период умирания языка в несколько раз превышает период его бурной молодости, так что ждать придётся долго.
Внезапно став мейнстримом, Ruby, из-за своей специализированности и, в некоторой мере, "сиротства" (ни одна всемирная корпорация не поддерживает язык, в отличие от практически любого другого популярного), занял позиции позади навязываемых организационно-административными мерами C++, Go, PHP, Python и др. в индексе "народной популярности" Stackoverflow (последний стал использоваться в качестве основного демагогического аргумента "бесконечного умирания" Ruby).
Зацените накал полемики: Ruby только-только дорос, по масштабам внедрения и популярности, до целесообразности попытки штурма Топ-10 рейтинга Stackoverflow. А отношение такое, как будто он уже успел влезть на первое место и оттуда скатиться на десятое. Откуда такая паника-то? Спокойней надо относиться, ребята, сдержанней.
Объективно, у Ruby/Rails есть существенный недостаток. Если на C++, Javaили КОБОЛе десять дедушек могут полтора года "строить архитектуру", "внедрять паттерны", "документировать и проектировать", вместо реализации бизнес-задач, то на Ruby два студента-старшекурсника за месяц делают MVP. Дедушке не хочется Ruby, ему хочется спокойной жизни. Дедушка напишет в блог, мол, я сорок лет в индустрии, пережил смерть алгола, кобола, эйпиэля, паскаля, ады и перла. И руби тоже туда отправится. Переживу.
Может быть.
Но рассмотрим второй вариант: дедушку самого отправят на пенсию.
На что ставим?
#programming #ruby
К 2017-2018 годам, через 6 лет после даты смерти (2011) и через 3 года после её публичного объявления (2014), Ruby достигает невиданной популярности. До этой поры будучи в общем-то нишевым языком, "себе на уме", инструментом для сравнительно небольшой группы приверженцев (хоть и постоянно растущей), Ruby/Rails становится абсолютным мейнстримом.
Напомню, что создатель Ruby on Rails, Дэвид Хейнмайер Хэнсон, в своей книге "Getting real" (можно перевести как-то вроде "Становясь реалистичным") писал как владелец небольшой компании другим владельцам (и сотрудникам) небольших компаний: ребята, умерьте аппетиты. Не надо мегаломанских целей типа стать фейсбуком. Поставьте скромную цель. Например, миллион баксов в год. Чистыми.
Не надо стремиться к публикациям в больших журналах, типа Wall Street. Занимайтесь маркетингом в своей нише.
Не надо стремиться купить домен из одного словарного слова. Берите любой подходящий, добавьте "app" если надо. Первый домен для приложения компании: basecamphq.com
Спустя годы, конечно, компания-разработчик Rails покупает домен "basecamp.com".
А уже в наше время купила домен "hey.com" (2020) для своего нового email-сервиса (цена не разглашается; из общих соображений, от сотен тысяч до нескольких миллионов долларов).
Про ряд публикаций в Wall Street и выход книги-бестселлера Rework и не говорю.
В компании Basecamp скромно поясняют, мол, к такому успеху не стремились, но к нему пришли.
Следом за успехом материнской компании, получает свои 15 минут славы и разработанный ей (с участием открытого сообщества) фреймворк.
Зарплата Ruby on Rails разработчика выходит на первую строку таблицы зарплат веб-разработчиков.
Ruby заходит одной ногой в топ-10 популярных языков. В последующие годы рекорд не побит: болтается с 10 по 15 место.
Феноменальный успех для нишевого языка, который не поддерживает ни одна всемирная корпорация, и который находился под постоянным коллективным прессингом со стороны агитаторов всех конкурентов.
И вот с этого момента, наконец, можно считать Ruby состоявшимся языком, который хотя бы в теории может начать умирать. По-моему, плато действительно пройдено. Что же, C++ умирает 25 лет. Java умирает 20 лет. .NET умирает 15 лет. Ну и Ruby ещё покочевряжится немножко, как минимум пока нынешние первокурсники не станут шестидесятилетними старичками и не уйдут на пенсию. Не трудно заметить, что период умирания языка в несколько раз превышает период его бурной молодости, так что ждать придётся долго.
Внезапно став мейнстримом, Ruby, из-за своей специализированности и, в некоторой мере, "сиротства" (ни одна всемирная корпорация не поддерживает язык, в отличие от практически любого другого популярного), занял позиции позади навязываемых организационно-административными мерами C++, Go, PHP, Python и др. в индексе "народной популярности" Stackoverflow (последний стал использоваться в качестве основного демагогического аргумента "бесконечного умирания" Ruby).
Зацените накал полемики: Ruby только-только дорос, по масштабам внедрения и популярности, до целесообразности попытки штурма Топ-10 рейтинга Stackoverflow. А отношение такое, как будто он уже успел влезть на первое место и оттуда скатиться на десятое. Откуда такая паника-то? Спокойней надо относиться, ребята, сдержанней.
Объективно, у Ruby/Rails есть существенный недостаток. Если на C++, Java
Может быть.
Но рассмотрим второй вариант: дедушку самого отправят на пенсию.
На что ставим?
#programming #ruby
Хроники умирания Ruby: 2020 и далее (6/6)
К 2020 году Ruby-сообщество окончательно пришло к выводу, что статус первоклассного языка, который был присвоен Ruby "явочным порядком" и без инициативы самого сообщества, накладывает некоторые обязательства, которые невольно надо пытаться выполнять. В частности, поддерживать градус ответной демагогии на должном уровне.
В прошлом году одна из крупнейших PHP-конференций не состоялась, потому что пару разработчиков-феминисток "выразили озабоченность" в связи с "недостаточным разнообразием [diversity]" спикеров. Организатор конференции, глупо хлопая глазами, оправдывался: "Да я... да вы что... да я же приглашал... да просто не было женщин желающих...". На что ему блюстители дайвёрсити строго, сдерживая справедливое раздражение, бросали: "Лучше искать надо было."
В этом плане у Ruby-сообщества несомненный бонус в виде создателя языка-японца и его коллег. Впрочем, как мы видим на примере Cyberpunk, даже при такой казалось бы железобетонной страховке, всерьёз начать докапываться всё равно могут. Но в ином случае было бы совсем плохо, с другой стороны.
Вообще, первая конференция по Ruby, на которую я пришёл, выглядела так: примерно десять человек в Москве встретились у метро. Списались через тематическую Google-группу. Один из участников заранее договорился со своим институтом (не первой величины), выделили кабинет, допустили на территорию. По очереди несколько человек о чём-то интересном рассказали, пиша мелом на доске. Про RSpec доклад был, про то, про сё. Поболтали душевно.
Одна из недавних конференций выглядела до локдауна вы сами знаете как. Официальные спонсоры. Огромная территория, снятая на несколько дней в пригороде. Тысячи участников. Докладчики первой величины со всего мира.
Попробуйте представить теперь, как я воспринимаю назойливо муссируемую идею о том, что Ruby, оказывается, умирает все эти годы. Моей первой реакцией является просто плюнуть и покрутить пальцем у виска: клинический неадекват. Но вот ради молодёжи (не в смысле возраста, а в смысле причастности к теме), которая не виновата в своей начальной неосведомлённости, решил расписать эту мысль чуть подробней.
Собственно, примерно такая же реакция у пока не до конца сориентировавшихся в "социальной реальности" зарубежных коллег. Пишутся статьи со сдержанным недоумением, мол, ребята, что вы нам сказки-то рассказываете: например, про низкую производительность Ruby/Rails? По сравнению с чем низкая? Уж не хуже, например, чем у Python/Django и PHP/Laravel.
"Не хуже" – это, конечно, вежливая сдержанность взрослого, чтобы не обидеть навязчивых подростков. Следующим бесхитростным ходом в борьбе инженеров с журналистами является такой: "А теперь Ruby стал в три раза быстрей. Третья версия." Мол, ну да, умираем, виноваты-с. Кочевряжимся вот как-то так, простите.
Ответным контр-ходом является вариация на тему "вы всё врёти", а именно мантра следующего сорта: "каждый инструмент подходит под свою задачу, нельзя однобоко смотреть на вещи, инженер должен уметь пользоваться чем дают, программист может изучить язык за две недели" и т.п.
На что инженер будет недоумённо хмуриться: мол, простите, а зачем мне кто-то будет рассказывать, что я должен говорить и даже думать(!), если я могу сам всё попробовать и объективно сравнить?
Сравнительный анализ инструментов для конкретной ниши разработки веб-приложений (в широком смысле) показывает, что Ruby/Rails – это самый технологичный инструмент на сегодняшний день. Вообще, на самом деле, рубисты плевать хотели и на Ruby, и на Rails, и не так уж сильно, открою секрет, любят эти технологии.
"Культ Rails" это "культ острых ножей для нарезания хлеба". "Почему ты острым ножом режешь, ведь есть десять тупых?" – "Ну дык, это, удобней ить" – "Ты, как инженер, должен уметь использовать разные инструменты, смотреть на технологии объективно, научиться пользоваться другим ножом можно за пару дней..." и пошло-поехало.
#programming #ruby
К 2020 году Ruby-сообщество окончательно пришло к выводу, что статус первоклассного языка, который был присвоен Ruby "явочным порядком" и без инициативы самого сообщества, накладывает некоторые обязательства, которые невольно надо пытаться выполнять. В частности, поддерживать градус ответной демагогии на должном уровне.
В прошлом году одна из крупнейших PHP-конференций не состоялась, потому что пару разработчиков-феминисток "выразили озабоченность" в связи с "недостаточным разнообразием [diversity]" спикеров. Организатор конференции, глупо хлопая глазами, оправдывался: "Да я... да вы что... да я же приглашал... да просто не было женщин желающих...". На что ему блюстители дайвёрсити строго, сдерживая справедливое раздражение, бросали: "Лучше искать надо было."
В этом плане у Ruby-сообщества несомненный бонус в виде создателя языка-японца и его коллег. Впрочем, как мы видим на примере Cyberpunk, даже при такой казалось бы железобетонной страховке, всерьёз начать докапываться всё равно могут. Но в ином случае было бы совсем плохо, с другой стороны.
Вообще, первая конференция по Ruby, на которую я пришёл, выглядела так: примерно десять человек в Москве встретились у метро. Списались через тематическую Google-группу. Один из участников заранее договорился со своим институтом (не первой величины), выделили кабинет, допустили на территорию. По очереди несколько человек о чём-то интересном рассказали, пиша мелом на доске. Про RSpec доклад был, про то, про сё. Поболтали душевно.
Одна из недавних конференций выглядела до локдауна вы сами знаете как. Официальные спонсоры. Огромная территория, снятая на несколько дней в пригороде. Тысячи участников. Докладчики первой величины со всего мира.
Попробуйте представить теперь, как я воспринимаю назойливо муссируемую идею о том, что Ruby, оказывается, умирает все эти годы. Моей первой реакцией является просто плюнуть и покрутить пальцем у виска: клинический неадекват. Но вот ради молодёжи (не в смысле возраста, а в смысле причастности к теме), которая не виновата в своей начальной неосведомлённости, решил расписать эту мысль чуть подробней.
Собственно, примерно такая же реакция у пока не до конца сориентировавшихся в "социальной реальности" зарубежных коллег. Пишутся статьи со сдержанным недоумением, мол, ребята, что вы нам сказки-то рассказываете: например, про низкую производительность Ruby/Rails? По сравнению с чем низкая? Уж не хуже, например, чем у Python/Django и PHP/Laravel.
"Не хуже" – это, конечно, вежливая сдержанность взрослого, чтобы не обидеть навязчивых подростков. Следующим бесхитростным ходом в борьбе инженеров с журналистами является такой: "А теперь Ruby стал в три раза быстрей. Третья версия." Мол, ну да, умираем, виноваты-с. Кочевряжимся вот как-то так, простите.
Ответным контр-ходом является вариация на тему "вы всё врёти", а именно мантра следующего сорта: "каждый инструмент подходит под свою задачу, нельзя однобоко смотреть на вещи, инженер должен уметь пользоваться чем дают, программист может изучить язык за две недели" и т.п.
На что инженер будет недоумённо хмуриться: мол, простите, а зачем мне кто-то будет рассказывать, что я должен говорить и даже думать(!), если я могу сам всё попробовать и объективно сравнить?
Сравнительный анализ инструментов для конкретной ниши разработки веб-приложений (в широком смысле) показывает, что Ruby/Rails – это самый технологичный инструмент на сегодняшний день. Вообще, на самом деле, рубисты плевать хотели и на Ruby, и на Rails, и не так уж сильно, открою секрет, любят эти технологии.
"Культ Rails" это "культ острых ножей для нарезания хлеба". "Почему ты острым ножом режешь, ведь есть десять тупых?" – "Ну дык, это, удобней ить" – "Ты, как инженер, должен уметь использовать разные инструменты, смотреть на технологии объективно, научиться пользоваться другим ножом можно за пару дней..." и пошло-поехало.
#programming #ruby
Я думаю, всё так и будет продолжаться примерно также, как идёт. Ruby будет "умирать", отмечая по ходу дела всё новые технические свершения. Особой популярности не будет (дедушки не хотят в кризис на пенсию), но и без особых провалов обойдётся. Rails приносит деньги. Миллиардерам деньги не нужны, за идею работают, а вот миллионерам (которые и финансируют разработку Ruby и Rails) очень даже нужны.
Миллионеры, конечно, тоже не сахар. И периодические шуточки DHH (известное добавление метода thirty_third или приколачивание ActionText прямо внутрь Rails) терпеть неприятно. Диалектику из серии: "А почему вы внедрили какой-то колхозный метод для запуска такого-то SQL-запроса, если три года назад трудящиеся вам присылали два варианта PR с нормальной реализацией (которые были отклонены)" - "А потому" – тоже. Возникает грустный вопрос в адрес всех этих JS/Node, Python/Django, PHP/Laravel, Java/Spring и остальных "трендов стековерфлоу": ребята, почему за 16 лет существования Ruby on Rails, в ряде случаев прямо заявив попытку скопировать Rails на своём языке, у вас не получилось ничего толкового? Ответа нет. Поэтому приходится терпеть.
#programming #ruby
Миллионеры, конечно, тоже не сахар. И периодические шуточки DHH (известное добавление метода thirty_third или приколачивание ActionText прямо внутрь Rails) терпеть неприятно. Диалектику из серии: "А почему вы внедрили какой-то колхозный метод для запуска такого-то SQL-запроса, если три года назад трудящиеся вам присылали два варианта PR с нормальной реализацией (которые были отклонены)" - "А потому" – тоже. Возникает грустный вопрос в адрес всех этих JS/Node, Python/Django, PHP/Laravel, Java/Spring и остальных "трендов стековерфлоу": ребята, почему за 16 лет существования Ruby on Rails, в ряде случаев прямо заявив попытку скопировать Rails на своём языке, у вас не получилось ничего толкового? Ответа нет. Поэтому приходится терпеть.
#programming #ruby
Очередная новость: Гугл пожертвует $350k на разработку Python.
То есть пожертвует в специальный "некоммерческий фонд", который занимается разработкой Питона: PSF.
Президентом фонда является Гвидо ван Россум, изначальный разработчик языка. Что ж, дело хорошее. Гвидо настоящий программист и знает своё дело (в отличие от Расмуса Ледорфа, разработчика PHP, который никогда способным программистом не был и за почти 30 лет разработки своего языка не потрудился хоть какой-то талант развить, и к программированию и программистам относится с демонстративным пренебрежением).
Одновременно, Гвидо работает в Microsoft, недавно выйдя из "официального ухода на пенсию". В 65 лет захотелось поработать фулл-тайм. Поработать не в своём фонде над своим языком, а в коммерческой компании.
Вот такой вот успешный язык.
Ну что ж, а куда пойдут деньги?
Посмотрим отчёт за предыдущий период (2019 год):
- по тысяче баксов каждому из сотни докладчиков международных конференций, на билеты и пиво ($140k)
- тудым, сюдым, проекты всякие, поддержка в Android ($250k)
- тудым, сюдым, организационные издержки, хостинги, всё такое ($50k)
- тудым, сюдым, тренинги всякие, "инициативы по всему миру" ($325k)
- тудым, сюдым, "усиление брендов", "торговые марки" ($270k)
- разработка python ($25k)
Ну то есть КПД фонда примерно 2.5% ($25k от $1M). Остальное ушло кому надо и на какие надо важные дела. При этом номинальный глава фонда вынужден в 65 лет снова выходить на работу.
Не трудно прикинуть, что даже если целиком годовое пожертвование Гугла направить на разработку Python, то его хватит на работу, в лучшем случае, двух хороших американских программистов.
По-моему это не поддержка, а насмешка какая-то.
#programming #python
То есть пожертвует в специальный "некоммерческий фонд", который занимается разработкой Питона: PSF.
Президентом фонда является Гвидо ван Россум, изначальный разработчик языка. Что ж, дело хорошее. Гвидо настоящий программист и знает своё дело (в отличие от Расмуса Ледорфа, разработчика PHP, который никогда способным программистом не был и за почти 30 лет разработки своего языка не потрудился хоть какой-то талант развить, и к программированию и программистам относится с демонстративным пренебрежением).
Одновременно, Гвидо работает в Microsoft, недавно выйдя из "официального ухода на пенсию". В 65 лет захотелось поработать фулл-тайм. Поработать не в своём фонде над своим языком, а в коммерческой компании.
Вот такой вот успешный язык.
Ну что ж, а куда пойдут деньги?
Посмотрим отчёт за предыдущий период (2019 год):
- по тысяче баксов каждому из сотни докладчиков международных конференций, на билеты и пиво ($140k)
- тудым, сюдым, проекты всякие, поддержка в Android ($250k)
- тудым, сюдым, организационные издержки, хостинги, всё такое ($50k)
- тудым, сюдым, тренинги всякие, "инициативы по всему миру" ($325k)
- тудым, сюдым, "усиление брендов", "торговые марки" ($270k)
- разработка python ($25k)
Ну то есть КПД фонда примерно 2.5% ($25k от $1M). Остальное ушло кому надо и на какие надо важные дела. При этом номинальный глава фонда вынужден в 65 лет снова выходить на работу.
Не трудно прикинуть, что даже если целиком годовое пожертвование Гугла направить на разработку Python, то его хватит на работу, в лучшем случае, двух хороших американских программистов.
По-моему это не поддержка, а насмешка какая-то.
#programming #python
Python software foundation: "фирма" работает
Немного взглянули в прошлый раз на бухгалтерию Python Software Foundation. Внешне организация маскируется под такое формальное легальное прикрытие сбора денег на нужды программистов (цель понятная и благородная). Суть компании описывается коротко и однозначно: "PSF – это организация, стоящая за Python".
Возвращаясь к нашему предыдущему материалу возникает, конечно, вопрос, почему КПД работы этой организации такой низкий, если декларируемая функция совпадает с реальной.
Среди "инициатив по всему миру", "популяризации программирования среди женщин", "поедании тако и поездках на велосипеде" (кратко об этом дальше) и других важных вещей, которыми занимаются сотрудники фонда, проскакивает кое-что, что всё же имеет непосредственное отношение к языку и инфраструктуре разработки: поддержка и развитие менеджера пакетов PyPI.
Результат многолетнего (двадцатилетнего, если считать от основания PSF) развития этого направления заключается в том, что PyPI, без оговорок, худший пакетный менеджер среди всех конкурентов. Даже Go, который в этом аспекте подвергался справедливой критике, всё же не был настолько позорно отставшим от передовых образцов. Даже NPM лучше: хотя, казалось бы, хуже и найти невозможно.
Гугл, кстати, закинул денег (см. прыдыдущий материал) в том числе на "аудит кода в PyPI". На то, чтобы сделать из PyPI продукт, которым не стыдно было бы пользоваться в "самом популярном динамическом языке", денег он, разумеется, не дал: Google поддерживает свою закрытую альтернативу, которой в определённых рамках после многошаговой регистрации даже можно пользоваться бесплатно.
Пакетный менеджер
То есть, на пальцах: чтобы понять, какую максимальную версию пакета А (заданную в манифесте как '1.*') можно использовать с пакетом B (версии, положим, тоже '1.*'),
Хорошо, эффективность выполнения PSF-ом своих прямых функций установили. Денег разработчикам сторонних решений (pipenv, например – приличный production-ready продукт, который можно просто взять и вмёрджить в основной дистрибутив python и закрыть вопрос) приниципиально решили не давать. На счетах PSF при этом скопилось 4 миллиона баксов. Чем же он занимается?
Достаточно посмотреть официальный список наёмных сотрудников, чтобы все вопросы снять. Полный список сотрудников и их обязанностей такой:
– директор (управление персоналом и трансляция воли совета директоров)
– счетовод, бухглатер и главный бухглатер (обязанности понятны)
– секретарь директора (сбор средств на благотворительных акциях, организация конференций)
– ивент-менеджер (организация конференций)
– Директор Инфраструктуры (заседание в комитетах, хостинг сайта python.org)
Про Директора Инфраструктуры, единственного айтишника среди всей команды, в официальном резюме сказано вот что: любит тако и кататься на велосипеде, притворяется что его любят кошки, а зовут его Ee W. Durbin III. Игра слов непереводимая и не до конца понятная, но ясно, что это что-то вроде "Вась И. Турбин Третий". При этом у человека есть и настоящее имя, конечно, в смысле по паспорту, но на лицевой странице фонда и в официальной переписке он предпочитает выступать Дурбин-Третьим. "Человек и пароход".
#programming #python
Немного взглянули в прошлый раз на бухгалтерию Python Software Foundation. Внешне организация маскируется под такое формальное легальное прикрытие сбора денег на нужды программистов (цель понятная и благородная). Суть компании описывается коротко и однозначно: "PSF – это организация, стоящая за Python".
Возвращаясь к нашему предыдущему материалу возникает, конечно, вопрос, почему КПД работы этой организации такой низкий, если декларируемая функция совпадает с реальной.
Среди "инициатив по всему миру", "популяризации программирования среди женщин", "поедании тако и поездках на велосипеде" (кратко об этом дальше) и других важных вещей, которыми занимаются сотрудники фонда, проскакивает кое-что, что всё же имеет непосредственное отношение к языку и инфраструктуре разработки: поддержка и развитие менеджера пакетов PyPI.
Результат многолетнего (двадцатилетнего, если считать от основания PSF) развития этого направления заключается в том, что PyPI, без оговорок, худший пакетный менеджер среди всех конкурентов. Даже Go, который в этом аспекте подвергался справедливой критике, всё же не был настолько позорно отставшим от передовых образцов. Даже NPM лучше: хотя, казалось бы, хуже и найти невозможно.
Гугл, кстати, закинул денег (см. прыдыдущий материал) в том числе на "аудит кода в PyPI". На то, чтобы сделать из PyPI продукт, которым не стыдно было бы пользоваться в "самом популярном динамическом языке", денег он, разумеется, не дал: Google поддерживает свою закрытую альтернативу, которой в определённых рамках после многошаговой регистрации даже можно пользоваться бесплатно.
Пакетный менеджер
pip не позволяет фиксировать версии (нет аналога Gemfile.lock или package-lock.js), ошибается в сложных (но встречающихся на практике) случаях разрешения зависимостей, и, как вишенка на торте, не умеет отдельно скачивать метаданные.То есть, на пальцах: чтобы понять, какую максимальную версию пакета А (заданную в манифесте как '1.*') можно использовать с пакетом B (версии, положим, тоже '1.*'),
pip-у, в общем случае, требуется полностью скачать из PyPI все версии пакетов А и B соответствующие маске (1.1, 1.2, 1.2.2, 1.3, и т.д.).Хорошо, эффективность выполнения PSF-ом своих прямых функций установили. Денег разработчикам сторонних решений (pipenv, например – приличный production-ready продукт, который можно просто взять и вмёрджить в основной дистрибутив python и закрыть вопрос) приниципиально решили не давать. На счетах PSF при этом скопилось 4 миллиона баксов. Чем же он занимается?
Достаточно посмотреть официальный список наёмных сотрудников, чтобы все вопросы снять. Полный список сотрудников и их обязанностей такой:
– директор (управление персоналом и трансляция воли совета директоров)
– счетовод, бухглатер и главный бухглатер (обязанности понятны)
– секретарь директора (сбор средств на благотворительных акциях, организация конференций)
– ивент-менеджер (организация конференций)
– Директор Инфраструктуры (заседание в комитетах, хостинг сайта python.org)
Про Директора Инфраструктуры, единственного айтишника среди всей команды, в официальном резюме сказано вот что: любит тако и кататься на велосипеде, притворяется что его любят кошки, а зовут его Ee W. Durbin III. Игра слов непереводимая и не до конца понятная, но ясно, что это что-то вроде "Вась И. Турбин Третий". При этом у человека есть и настоящее имя, конечно, в смысле по паспорту, но на лицевой странице фонда и в официальной переписке он предпочитает выступать Дурбин-Третьим. "Человек и пароход".
#programming #python
Понятно, что на всю Америку, несомненно, нашёлся бы хотя бы один программист, который мог бы за всю тусовку бухгалтеров пополам с ивент-менеджерами изображать (хотя бы из соображений естественной социальной маскировки) хардкорный технический уклон фирмы. Мол, ничего, что у нас тут собрались одни "организаторы", я за десятерых решаю вопросы развития языка и делаю по два PR в неделю, поэтому меня и одного хватит. Такие люди ведь есть. Назначение Дурбина-Третьего, поэтому, с такой специфической автобиографией, выглядит отнюдь не недоработкой, а демонстративным жестом: плевать нам на вас, гики, и так съедите и будете ходить на наши конференции по стагнирующему языку и платить деньги как миленькие, ещё и прыгать от радости. (И ходят, и платят, и прыгают.)
Итак, фирма занимается организацией ивентов. Команда подобралась сбалансированная.
Эту же команду можно поставить на организацию ивентов по защите прав кошек и собак небольшого роста (вместо Дурбина взять Кошкину, активистку и владелицу домашнего питомника на 15 голов), региональных авторалли (последнего члена команды заменить на автослесаря Петровича, кхм, в смысле, Джонсона, из соседней мастерской), продвижения депутатов городского совета небольших региональных центров, и т.п. И поставят, как выдохнется текущее направление работы.
В этом смысле понятен акцент в отчётности на "узнавании брендов" и "охвате конференций", и отсутствие ссылок на вклад в развитие языка и платформы. Это попросту не их профиль, о чём они, фактически, открыто сообщают.
Здесь, конечно, расчёт на то, что программисты – совсем тупые и не понимают, что если в развитие языка реально не вкладываться, то разработка на нём очень быстро станет очень унылой. Это ведь не политика, где тамада может прыгать до бесконечности, тут конкретный измеримый продукт на выходе есть. Или, в данном случае, нет.
Что ж, увы, в какой-то мере это правда. Но, в отличие от многих других сфер труда, в программировании очень хорошо работает (в определённых границах) естественная селекция: чем умнее, тем больше зарабатывает.
Языки для бедных тоже нужны.
#programming #python
Итак, фирма занимается организацией ивентов. Команда подобралась сбалансированная.
Эту же команду можно поставить на организацию ивентов по защите прав кошек и собак небольшого роста (вместо Дурбина взять Кошкину, активистку и владелицу домашнего питомника на 15 голов), региональных авторалли (последнего члена команды заменить на автослесаря Петровича, кхм, в смысле, Джонсона, из соседней мастерской), продвижения депутатов городского совета небольших региональных центров, и т.п. И поставят, как выдохнется текущее направление работы.
В этом смысле понятен акцент в отчётности на "узнавании брендов" и "охвате конференций", и отсутствие ссылок на вклад в развитие языка и платформы. Это попросту не их профиль, о чём они, фактически, открыто сообщают.
Здесь, конечно, расчёт на то, что программисты – совсем тупые и не понимают, что если в развитие языка реально не вкладываться, то разработка на нём очень быстро станет очень унылой. Это ведь не политика, где тамада может прыгать до бесконечности, тут конкретный измеримый продукт на выходе есть. Или, в данном случае, нет.
Что ж, увы, в какой-то мере это правда. Но, в отличие от многих других сфер труда, в программировании очень хорошо работает (в определённых границах) естественная селекция: чем умнее, тем больше зарабатывает.
Языки для бедных тоже нужны.
#programming #python
Недавно рассматривали организационную экосистему Python. В принципе, все всё правильно поняли.
Как точно резюмировал один из читателей: "постмодерн".
Другой читатель, посмотрев на фотографию директора Python Software Foundation, критично (в мой адрес) прокомментировал: "ну, ты бы ещё поставил ей в упрёк, что у неё в интересах «дивёрсити» указано!". Но позвольте, я ведь просто выложил фотографию с подписью, которую человек сам о себе с гордостью демонстрирует, практически, на своём официальном сайте. Мне показался такой упрёк забавным и показательным, я и сам что-то подобное чувствовал при написании текста: иррационально кажется, что прямое дословное цитирование чьих-то пиар ходов одновременно является как бы критикой автора этих ходов. С одной стороны, хорошо бы при пересказе чьей-то позиции по ходу заочной полемики, по возможности, сглаживать острые углы, если человек явно ошибся. Но в случае фирмы, специализирующейся на популяризации самой себя, ошибки в демонстративных жестах никакой быть не может, это целенаправленная самопрезентация.
Хотел дальше по этой линии постов вкратце разобрать список учредителей PSF (в отличие от показанной ранее "исполнительной" части организации, там есть "содержательные" персонажи). Но пока отложим: думаю, надо нам всем ещё поработать над собой, над повышением уровня толерантности и ментального самоконтроля, чтобы от рассмотрения профилей значимых общественных деятелей (самими этими деятелями о себе и написанных) возникала положенная цивилизованному человеку автоматическая улыбка и чувство эмпатии, а не сложная композиция плохо "диверсифицированных" мыслей.
Перескочим сразу на следующую тему (в этой линии тем). JetBrains участвует в кампании по сбору средств на Django (деньги собирает отдельная организация) – отчисляет все поступления с продаж IDE PyCharm в Django Software Foundation. Дело стоящее, давайте в меру сил и доступных средств поучаствуем в популяризации хорошего языка и фреймворка.
Участвовать будем путём критического анализа отдельных аспектов фреймворка и сопутствующей инфраструктуры. Материал будет потихоньку выкладываться.
#programming #django #python
Как точно резюмировал один из читателей: "постмодерн".
Другой читатель, посмотрев на фотографию директора Python Software Foundation, критично (в мой адрес) прокомментировал: "ну, ты бы ещё поставил ей в упрёк, что у неё в интересах «дивёрсити» указано!". Но позвольте, я ведь просто выложил фотографию с подписью, которую человек сам о себе с гордостью демонстрирует, практически, на своём официальном сайте. Мне показался такой упрёк забавным и показательным, я и сам что-то подобное чувствовал при написании текста: иррационально кажется, что прямое дословное цитирование чьих-то пиар ходов одновременно является как бы критикой автора этих ходов. С одной стороны, хорошо бы при пересказе чьей-то позиции по ходу заочной полемики, по возможности, сглаживать острые углы, если человек явно ошибся. Но в случае фирмы, специализирующейся на популяризации самой себя, ошибки в демонстративных жестах никакой быть не может, это целенаправленная самопрезентация.
Хотел дальше по этой линии постов вкратце разобрать список учредителей PSF (в отличие от показанной ранее "исполнительной" части организации, там есть "содержательные" персонажи). Но пока отложим: думаю, надо нам всем ещё поработать над собой, над повышением уровня толерантности и ментального самоконтроля, чтобы от рассмотрения профилей значимых общественных деятелей (самими этими деятелями о себе и написанных) возникала положенная цивилизованному человеку автоматическая улыбка и чувство эмпатии, а не сложная композиция плохо "диверсифицированных" мыслей.
Перескочим сразу на следующую тему (в этой линии тем). JetBrains участвует в кампании по сбору средств на Django (деньги собирает отдельная организация) – отчисляет все поступления с продаж IDE PyCharm в Django Software Foundation. Дело стоящее, давайте в меру сил и доступных средств поучаствуем в популяризации хорошего языка и фреймворка.
Участвовать будем путём критического анализа отдельных аспектов фреймворка и сопутствующей инфраструктуры. Материал будет потихоньку выкладываться.
#programming #django #python
В целом если вы видели один MVC фреймворк, вы видели их все. Переходя с Rails на Django (и наоборот) вы, может быть, ожидаете увидеть какие-то различия, но на самом деле всё в точности то же самое.
Однако при более подробном всматривании и ощупывании всплывает этакий программистский вариант "ложных друзей переводчика". И там, и там есть applications ("приложения"), migrations ("миграции"), views ("представления", здесь перевод не устоявшийся и их обычно "вьюхами" и называют). Но все эти штуки в обоих фреймворках либо существенно отличаются, либо обозначают просто разные вещи.
Вот планирую в небольшом цикле заметок остановиться именно на таких различиях, а сходство больше и не упоминать.
В Django опорный паттерн называется MVT, model-view-template. В Rails он называется MVC, model-view-controller. Разница только терминологическая: то что в Rails называют views (перемешанные фрагменты HTML-кода и управляющих операторов), в Django называют templates. То, что в Rails называют controllers (класс, обрабатывающий запрос) в Django называют views (может быть классом, а может быть отдельной функцией). Здесь достаточно один раз привыкнуть, задать риторический вопрос "зачем надо было всё перемешивать?", и дальше спокойно работать.
В Rails слово application, "приложение", синонимично слову project, "проект". То есть это вот весь код, простите за тавтологию, Rails-приложения, который вы храните в отдельном репозитории. В Django проторенными дорожками не ходят, поэтому там application это отдельный пакет внутри вашего проекта.
На пакетах (packages) стоит остановиться подробней. В Rails за вас работает система автоимпорта и весь код (при настройках по умолчанию) загружается в память при старте (на тонкостях останавливаться не будем).
Если в папке
В Django всё не так просто.
Во-первых, вам всегда надо вручную импортировать классы из пакетов:
В строке импорта выше
Для того, чтобы всё заработало, вам надо добавить строку "car_service" в массив подключенных приложений (
Поэтому, переходя с Rails на Django, надо понять, что весь код программисты конкретного приложения разбили, произвольно, на набор вот этих пакетов-приложений, и модель Car вы найдёте в файле
#programming #django #python
Однако при более подробном всматривании и ощупывании всплывает этакий программистский вариант "ложных друзей переводчика". И там, и там есть applications ("приложения"), migrations ("миграции"), views ("представления", здесь перевод не устоявшийся и их обычно "вьюхами" и называют). Но все эти штуки в обоих фреймворках либо существенно отличаются, либо обозначают просто разные вещи.
Вот планирую в небольшом цикле заметок остановиться именно на таких различиях, а сходство больше и не упоминать.
В Django опорный паттерн называется MVT, model-view-template. В Rails он называется MVC, model-view-controller. Разница только терминологическая: то что в Rails называют views (перемешанные фрагменты HTML-кода и управляющих операторов), в Django называют templates. То, что в Rails называют controllers (класс, обрабатывающий запрос) в Django называют views (может быть классом, а может быть отдельной функцией). Здесь достаточно один раз привыкнуть, задать риторический вопрос "зачем надо было всё перемешивать?", и дальше спокойно работать.
В Rails слово application, "приложение", синонимично слову project, "проект". То есть это вот весь код, простите за тавтологию, Rails-приложения, который вы храните в отдельном репозитории. В Django проторенными дорожками не ходят, поэтому там application это отдельный пакет внутри вашего проекта.
На пакетах (packages) стоит остановиться подробней. В Rails за вас работает система автоимпорта и весь код (при настройках по умолчанию) загружается в память при старте (на тонкостях останавливаться не будем).
Если в папке
app/models/car.rb лежит класс Car, то вам достаточно в коде написать Car, и Rails его найдут.В Django всё не так просто.
Во-первых, вам всегда надо вручную импортировать классы из пакетов:
from car_service.models import Car. В этом есть плюс: IDE всегда знает, откуда что взялось. Минус: существенное увеличение boilerplate-а и когнитивной нагрузки на его обслуживание.В строке импорта выше
car_service это, в терминах Python, имя пакета (имя выбрано произвольно: допустим, мы делаем бэкофис для автомастерской). А в терминах DJango, это имя "приложения" (application). models.py – имя файла, где лежит исходный код класса Car. Да, в Django в один файл принято запихивать десяток классов. Это одно из многих проявлений знаменитого питоновского акцента на красоту и элегантность кода.Для того, чтобы всё заработало, вам надо добавить строку "car_service" в массив подключенных приложений (
INSTALLED_APPS) в settings.py (файл настроек проекта). (Кстати, термин application здесь в итоге близок тому, как он понимается в экосистеме Elixir/Phoenix.) В терминах Rails этому car_service нет прямого аналога, иногда что-то подобное можно назвать "ресурсом" (resource, в терминах REST), иногда bounded context (опять же в Phoenix более прямые аналоги).Поэтому, переходя с Rails на Django, надо понять, что весь код программисты конкретного приложения разбили, произвольно, на набор вот этих пакетов-приложений, и модель Car вы найдёте в файле
car_service/models.py, а модель User в папке accounts/models.py.#programming #django #python
Питоновские пакеты, из-за обязательного явного импорта, могут экспортировать не только классы, но и переменные или константы:
Как было сказано выше, в Django в роли "вьюх" (т.е., в терминах Rails, "контроллеров") могут выступать отдельные функции. А могут и классы. Первое называется function based views, а второе class based views.
Привыкшему к REST веб-разработчику сподручнее сразу использовать class based views, чтобы не получать очередного когнитивного диссонанса от использования конструкций вроде
#programming #django #python
# some_file.pyПолучается своеобразная двойная иерархия: классы наследуют друг друга, а пакеты друг из друга импортируют всякую всячину. Поэтому в Питоне, где можно, частенько классы и не создают, просто группируют функции внутри файла (и файлы внутри пакета), и импортируют их в других файлах (и других пакетах). В Ruby для создания коллекции функций обязательно использовать, по меньшей мере, модули (modules); но вообще в качестве стандартной единицы распространения кода выступает класс, при этом имя файла (по соглашению/кодстайлу) однозначно соответствует имени класса (и в одном файле всегда только один класс).
NUMBER = 1
# another_file.py
from .some_file import NUMBER
print(NUMBER) #=> 1
Как было сказано выше, в Django в роли "вьюх" (т.е., в терминах Rails, "контроллеров") могут выступать отдельные функции. А могут и классы. Первое называется function based views, а второе class based views.
Привыкшему к REST веб-разработчику сподручнее сразу использовать class based views, чтобы не получать очередного когнитивного диссонанса от использования конструкций вроде
if request.method == 'POST' в мейнстримном фреймворке, созданном на самом элегантном языке программирования.#programming #django #python
Следующее существенное отличие Django от Rails это система миграций
В Rails миграции это просто тонкая обёртка над SQL-кодом: добавь такой-то столбец, удали такой и т.д. Все миграции хранятся в одной папке в хронологическом порядке. Движок определяет, какие миграции прошли, на основе того, есть ли отметка о данной миграции в специальной служебной таблице в базе данных.
В Django тоже есть аналогичная таблица, но этим дело не заканчивается. Во-первых, миграции разделены по "приложениями" (см. выше). В каждом приложении хранятся миграции (по конвенции), касающиеся моделей этого приложения. Вместо подразумеваемой цепочки зависимостей из Rails (где мы, фактически, считаем, что каждая миграция зависит от всех по времени более ранних), в Django в начале каждой миграции явно указывается, от каких предыдущих она зависит (они могут быть из других "приложений"). Получается сложный граф зависимостей.
Представим, что во время рефакторинга мы удалили некое "приложение" или два "приложения" объединили в одно. Что происходит с миграциями? Происходит, как можно догадаться, fuck up beyond all repair. Вам придётся либо оставить миграции в покое (удалив из устаревшего "приложения" все другие файлы), либо переписать все миграции, фактически, с нуля. Элегантному фреймворку – элегантные решения.
Далее важно понять, что в Django миграции это не простые прямолинейные команды для движка. Это декларация о том, что должно быть в базе данных. Когда мы пишем в миграции А "добавить столбец X, Y", а в миграции B (следующей по времени позже A) "добавить столбец Z, удалить столбец X", движок (во время исполнения миграций, когда он считывает все файлы) понимает: "ага, у нас в базе сейчас столбцы Y, Z" (важно отметить, что к базе данных при этом он подключается только для получения списка уже сделанных миграций – если вы там сами что-то наворотили отдельно, то всё сломается).
Django формирует, на основе виртуального суммирования всех миграций, некое своё (точное) представление о том, какая сейчас структура в БД (исходя из того, что она создавалась исключительно миграциями). Это называется State, "состояние".
Затем Django доходит до миграций, которые ещё не были выполнены, и выполняет соответствующие SQL-инструкции (database operations). Здесь операция вроде "добавить столбец M" выступает уже в двух ролях:
– во-первых, как database operation (аналогично Rails) – инструкции буквально выполнить
Как можно было предполагать, этот изящный подход к проблеме от, как складывается впечатление, какого-то победителя региональных олимпиад по computer science, в реальных приложениях работает отлично 80% времени. Оставшиеся 20% времени вам потребуется, вырывая волосы на голове, вгрызаться в (довольно сложный, но всё же за пару дней можно разобраться) DSL миграций и писать миграции типа SeparateDatabaseAndState (это когда вы буквально говорите Django, мол, я сам в базе произведу нужные операции, не надо "читать мысли", а потом отдельно ещё ему объясняете для этого "внутреннего образа схемы БД", что же вы сделали).
Тема миграций напрямую связана с темой моделей. Модели в Django требуют явного указания полей (похоже на gem DataMapper), в то время как в Rails поля подгружаются в рантайме из базы данных. Явное указание полей модели позволяет делать "автомиграции" – написать команду, которая (в соответствии с теми изменениями, что вы внесли в моделях, сравнивая их со State, который был вычислен из предыдущих миграций) сгенерирует миграцию, в которой удаляются (добавляются, изменяются) соответствующие поля. Это издевательски небольшая, но иррационально приятная компенсация за все прочие мучения.
#programming #django
В Rails миграции это просто тонкая обёртка над SQL-кодом: добавь такой-то столбец, удали такой и т.д. Все миграции хранятся в одной папке в хронологическом порядке. Движок определяет, какие миграции прошли, на основе того, есть ли отметка о данной миграции в специальной служебной таблице в базе данных.
В Django тоже есть аналогичная таблица, но этим дело не заканчивается. Во-первых, миграции разделены по "приложениями" (см. выше). В каждом приложении хранятся миграции (по конвенции), касающиеся моделей этого приложения. Вместо подразумеваемой цепочки зависимостей из Rails (где мы, фактически, считаем, что каждая миграция зависит от всех по времени более ранних), в Django в начале каждой миграции явно указывается, от каких предыдущих она зависит (они могут быть из других "приложений"). Получается сложный граф зависимостей.
Представим, что во время рефакторинга мы удалили некое "приложение" или два "приложения" объединили в одно. Что происходит с миграциями? Происходит, как можно догадаться, fuck up beyond all repair. Вам придётся либо оставить миграции в покое (удалив из устаревшего "приложения" все другие файлы), либо переписать все миграции, фактически, с нуля. Элегантному фреймворку – элегантные решения.
Далее важно понять, что в Django миграции это не простые прямолинейные команды для движка. Это декларация о том, что должно быть в базе данных. Когда мы пишем в миграции А "добавить столбец X, Y", а в миграции B (следующей по времени позже A) "добавить столбец Z, удалить столбец X", движок (во время исполнения миграций, когда он считывает все файлы) понимает: "ага, у нас в базе сейчас столбцы Y, Z" (важно отметить, что к базе данных при этом он подключается только для получения списка уже сделанных миграций – если вы там сами что-то наворотили отдельно, то всё сломается).
Django формирует, на основе виртуального суммирования всех миграций, некое своё (точное) представление о том, какая сейчас структура в БД (исходя из того, что она создавалась исключительно миграциями). Это называется State, "состояние".
Затем Django доходит до миграций, которые ещё не были выполнены, и выполняет соответствующие SQL-инструкции (database operations). Здесь операция вроде "добавить столбец M" выступает уже в двух ролях:
– во-первых, как database operation (аналогично Rails) – инструкции буквально выполнить
ALTER TABLE...
– во-вторых, как state operation – инструкции обновить "внутренний образ" того, какая у нас текущая структура базы данныхКак можно было предполагать, этот изящный подход к проблеме от, как складывается впечатление, какого-то победителя региональных олимпиад по computer science, в реальных приложениях работает отлично 80% времени. Оставшиеся 20% времени вам потребуется, вырывая волосы на голове, вгрызаться в (довольно сложный, но всё же за пару дней можно разобраться) DSL миграций и писать миграции типа SeparateDatabaseAndState (это когда вы буквально говорите Django, мол, я сам в базе произведу нужные операции, не надо "читать мысли", а потом отдельно ещё ему объясняете для этого "внутреннего образа схемы БД", что же вы сделали).
Тема миграций напрямую связана с темой моделей. Модели в Django требуют явного указания полей (похоже на gem DataMapper), в то время как в Rails поля подгружаются в рантайме из базы данных. Явное указание полей модели позволяет делать "автомиграции" – написать команду, которая (в соответствии с теми изменениями, что вы внесли в моделях, сравнивая их со State, который был вычислен из предыдущих миграций) сгенерирует миграцию, в которой удаляются (добавляются, изменяются) соответствующие поля. Это издевательски небольшая, но иррационально приятная компенсация за все прочие мучения.
#programming #django
Rails-разработчик, однажды наступив на грабли, знает, что в миграциях нельзя использовать код моделей. Модель может быть изменена или удалена, а миграция (в идеале) должна работать "с нуля" на свежей версии кода.
Django, будучи способным вычислить State, знает, какие поля у каких моделей в какой момент времени (на момент исполнения какой миграции) существовали. Поэтому внутри миграции вы, через специальный DSL, можете получить "призрак" класса своей модели на момент прохождения данной миграции: в ней будут все стандартные методы и ассоциации (но, конечно, все кастомные методы будут недоступны).
#programming #django
Django, будучи способным вычислить State, знает, какие поля у каких моделей в какой момент времени (на момент исполнения какой миграции) существовали. Поэтому внутри миграции вы, через специальный DSL, можете получить "призрак" класса своей модели на момент прохождения данной миграции: в ней будут все стандартные методы и ассоциации (но, конечно, все кастомные методы будут недоступны).
#programming #django
Нативная интеграция с самим собой
В пятницу планирую с 19:00 до 20:00 по Москве провести занятие "Лаборатории Metapractice" (онлайн).
Metapractice – opensource сообщество по психологическому моделированию человеческой активности.
Занятие будет посвящено "Авторефреймингу": установке в своё подсознание "резидентной программы" для решения (эмоциональных, психологических, поведенческих) проблем во сне. Звучит несколько претенциозно, я понимаю, но мы сейчас на переломе веков находимся: психологическая лексика и концепции устаревают, появляются удачные метафоры из области программирования (искусственные "нейросети" становятся, в чём-то парадоксально, метафорой для естественных), но технологии "нейропрограммирования" при этом тоже находятся в зачаточном состоянии.
Приходится использовать "инженерный" язык, несколько обгоняющий время, для описания моделей, которые являются закономерным развитием классиков психотехники.
Занятие будет в значительной мере тестовое (поэтому цена невысокая), с прицелом на серию повторных тематических встреч, если тема вызовет интерес. Потихоньку нащупаю манеру подачи и контент, вызывающий активный интерес трудящихся. Из-за неконвенциональности материала это займёт какое-то время, но эра "психологии в метафоре программирования" явно наступает. Надо хотя бы азы программирования человеческой активности освоить на примерах, чтобы рассуждения в mass media на эту тему и результаты очередных экспериментов с засовыванием головы живых существ в томограф понимались в правильном контексте.
Запись по ссылке:
https://metapractice.livejournal.com/600132.html
#psychology #courses
В пятницу планирую с 19:00 до 20:00 по Москве провести занятие "Лаборатории Metapractice" (онлайн).
Metapractice – opensource сообщество по психологическому моделированию человеческой активности.
Занятие будет посвящено "Авторефреймингу": установке в своё подсознание "резидентной программы" для решения (эмоциональных, психологических, поведенческих) проблем во сне. Звучит несколько претенциозно, я понимаю, но мы сейчас на переломе веков находимся: психологическая лексика и концепции устаревают, появляются удачные метафоры из области программирования (искусственные "нейросети" становятся, в чём-то парадоксально, метафорой для естественных), но технологии "нейропрограммирования" при этом тоже находятся в зачаточном состоянии.
Приходится использовать "инженерный" язык, несколько обгоняющий время, для описания моделей, которые являются закономерным развитием классиков психотехники.
Занятие будет в значительной мере тестовое (поэтому цена невысокая), с прицелом на серию повторных тематических встреч, если тема вызовет интерес. Потихоньку нащупаю манеру подачи и контент, вызывающий активный интерес трудящихся. Из-за неконвенциональности материала это займёт какое-то время, но эра "психологии в метафоре программирования" явно наступает. Надо хотя бы азы программирования человеческой активности освоить на примерах, чтобы рассуждения в mass media на эту тему и результаты очередных экспериментов с засовыванием головы живых существ в томограф понимались в правильном контексте.
Запись по ссылке:
https://metapractice.livejournal.com/600132.html
#psychology #courses
Livejournal
Лаборатория Metapractice (37) Говорит Москва: пробуем онлайн-формат через Zoom
https://metapractice.livejournal.com/551080.html Где и когда Пятница, 7.05.2021, 19:00-20:00 по Москве. Ссылка на встречу в Zoom придёт на ваш e-mail (после записи, перед занятием). UPD. Ссылка на встречу отправлена. Убедитесь, что получили. Формат и тема…
Пошли серьёзные разговоры об отмене ЕГЭ
Оставим в стороне гуманитарные предметы – всё же ни СССР, мягко говоря, первенством в гуманитарных науках не славился, ни Россия, по наследству. Гуманитарные науки у нас считаются вторичными ("гуманитарное образование – это отсутствие технического" и всё такое прочее). Важно понимать, что в цивилизованных странах Европы всё с точностью до наоборот: технически науки считаются вторичными по сравнению с гуманитарными. Образованный человек должен знать латынь, древнегреческий и классическую философию; прикасаться к техническим наукам это ниже достоинства и может быть оправдано только бизнесом на очень большие деньги (в США, кстати, другое отношение). Условный Ernst & Young в российских ВУЗах набирает аналитиков (в том числе) из изучающих профессионально физику. В Английских ВУЗах – из изучающих профессионально теологию. Не трудно догадаться, что английские теологи могут, в силу положения и имеющихся компетенций, командовать российскими физиками, но никак не наоборот.
Но до некоторого времени техническое образование в России было массовым и, в целом, неплохим. При сравнительно небольших усилиях (со стороны самого ученика или со стороны родителей) школьник из глубокой провинции мог поступить в пять ведущих ВУЗов одновременно и переехать в Москву. Не требовалось ни мотивирующего письма, ни собеседования, ни характеристики со школы, ни рекомендаций преподавателей, ни участия в кружках-секциях-конференциях, ни принадлежность к какому-нибудь меньшинству, ни несписываемого при личном банкротстве кредита размером в пару годовых зарплат специалиста высокого уровня. Соотношения лёгкости поступления и качества получаемого образования было беспрецедентно высоким.
Надо было всего лишь сдать один экзамен в конце обучения в школе (сдать у себя в городе, никуда не уезжая) при наличии развитой инфраструктуры подготовки к этому экзамену в любой форме (хоть просто на школьных занятиях, хоть с дополнительной литературой, хоть в кружках, хоть по ютюб-видео, хоть с репетитором).
Экзаменационные задачи были удачно подобраны и, в целом (с поправкой на грандиозный масштаб процесса) объективно проверялись. Получаемый балл беспристрастно позволял разделить школьников на страты: кого вообще нельзя допускать к любой серьёзной работе, кому в техникум, кому формальное высшее, кому полноценное (по крайней мере, если уклон школьника был техническим) образование.
Видимо, социальный лифт оказался неожиданно мощным и "брать скрипача, который лучше играет" (см. известный анекдот) больше неприемлемо.
Детей в любом случае жалко, но вот жалко ли родителей? Мне нет, хотя некую экзистенциальную (следовательно, отстранённую) печаль испытываю. Все эти годы раздавался голос как бы из народных масс: "ЕГЭ отупляет", "поколение ЕГЭ", "натаскивание на ЕГЭ"; разноголосый гул как бы пролетарской оппозиции. Гул голосов людей, которые даже в общих чертах не представляют саму СТРУКТУРУ, например, экзамена по математике, уж не говорю о том чтобы вчитаться в содержание. Скажем, в современном экзамене вообще нет задач типа "выберите верный ответ из предложенных вариантов" – как такой простой факт может быть малоизвестным, если экзамен проводится с миллионным размахом каждый год? А вот так.
Но ни одного объединения родителей (хотя, в отличие от многих других областей, школьное обучение ведь по естественным причинам "профсоюзоёмкое"), насколько я знаю, отчётливо не сказало "а мы ЗА ЕГЭ!".
Поэтому, не столько жалко этих родителей, сколько печально от той безнадёжной простоты, с которой людей убедили, что "понизить им градус" это им же на пользу. Да какой убедили, те сами просили все эти годы.
#education
Оставим в стороне гуманитарные предметы – всё же ни СССР, мягко говоря, первенством в гуманитарных науках не славился, ни Россия, по наследству. Гуманитарные науки у нас считаются вторичными ("гуманитарное образование – это отсутствие технического" и всё такое прочее). Важно понимать, что в цивилизованных странах Европы всё с точностью до наоборот: технически науки считаются вторичными по сравнению с гуманитарными. Образованный человек должен знать латынь, древнегреческий и классическую философию; прикасаться к техническим наукам это ниже достоинства и может быть оправдано только бизнесом на очень большие деньги (в США, кстати, другое отношение). Условный Ernst & Young в российских ВУЗах набирает аналитиков (в том числе) из изучающих профессионально физику. В Английских ВУЗах – из изучающих профессионально теологию. Не трудно догадаться, что английские теологи могут, в силу положения и имеющихся компетенций, командовать российскими физиками, но никак не наоборот.
Но до некоторого времени техническое образование в России было массовым и, в целом, неплохим. При сравнительно небольших усилиях (со стороны самого ученика или со стороны родителей) школьник из глубокой провинции мог поступить в пять ведущих ВУЗов одновременно и переехать в Москву. Не требовалось ни мотивирующего письма, ни собеседования, ни характеристики со школы, ни рекомендаций преподавателей, ни участия в кружках-секциях-конференциях, ни принадлежность к какому-нибудь меньшинству, ни несписываемого при личном банкротстве кредита размером в пару годовых зарплат специалиста высокого уровня. Соотношения лёгкости поступления и качества получаемого образования было беспрецедентно высоким.
Надо было всего лишь сдать один экзамен в конце обучения в школе (сдать у себя в городе, никуда не уезжая) при наличии развитой инфраструктуры подготовки к этому экзамену в любой форме (хоть просто на школьных занятиях, хоть с дополнительной литературой, хоть в кружках, хоть по ютюб-видео, хоть с репетитором).
Экзаменационные задачи были удачно подобраны и, в целом (с поправкой на грандиозный масштаб процесса) объективно проверялись. Получаемый балл беспристрастно позволял разделить школьников на страты: кого вообще нельзя допускать к любой серьёзной работе, кому в техникум, кому формальное высшее, кому полноценное (по крайней мере, если уклон школьника был техническим) образование.
Видимо, социальный лифт оказался неожиданно мощным и "брать скрипача, который лучше играет" (см. известный анекдот) больше неприемлемо.
Детей в любом случае жалко, но вот жалко ли родителей? Мне нет, хотя некую экзистенциальную (следовательно, отстранённую) печаль испытываю. Все эти годы раздавался голос как бы из народных масс: "ЕГЭ отупляет", "поколение ЕГЭ", "натаскивание на ЕГЭ"; разноголосый гул как бы пролетарской оппозиции. Гул голосов людей, которые даже в общих чертах не представляют саму СТРУКТУРУ, например, экзамена по математике, уж не говорю о том чтобы вчитаться в содержание. Скажем, в современном экзамене вообще нет задач типа "выберите верный ответ из предложенных вариантов" – как такой простой факт может быть малоизвестным, если экзамен проводится с миллионным размахом каждый год? А вот так.
Но ни одного объединения родителей (хотя, в отличие от многих других областей, школьное обучение ведь по естественным причинам "профсоюзоёмкое"), насколько я знаю, отчётливо не сказало "а мы ЗА ЕГЭ!".
Поэтому, не столько жалко этих родителей, сколько печально от той безнадёжной простоты, с которой людей убедили, что "понизить им градус" это им же на пользу. Да какой убедили, те сами просили все эти годы.
#education