У меня похожая история кончились переходом на Mint и "Gnome здорового человека" aka Cinnamon в 2017 году.
До этого за 20 лет использования линуксов перепробовал почти всё интересное в плане десктопов, от enlightenment-а до unity, компизовским кубиком виндузятников впетатлял :)
Сейчас просто работаю, 90% времени - проектирование, кодинг, работа с LLM и браузер.
У меня на питоне несколько больших живых сервисов у разных заказчиков и прототипирование всего протокольного, что потом переписывается на плюсы ради высокой производительности, такой цикл разработки крайне хорошо себя показал :)
Постановка вопроса смешная, на самом деле. Каждый дополнительный язык - это дополнительные возможности. Рискну предположить, что среди дата-сайнтистов пайтон на уровне понимания внутренних механизмов работы знают единицы.
ИИ-генерация типовых приложений, безусловно, будет процветать, и каждый желающий сможет с помощью нейросетки создать собственный minesweeper :)
А вот там, где для решения нужно придумывать, ИИ-кодер человеку - не конкурент. Хотя бы просто потому, что для верного решения нужно корректно поставить задачу и проконтролировать результат, что, как правило, требует приличного понимания программирования и общего computer sience.
Я имею значительный успешный опыт использования ИИ-кодеров в режиме "парного программирования" (прикладной и системный софт), но я хорошо понимаю, что именно пишет ИИ и как это проверить и исправить.
Это общее. Так же хорошо виден код вебовского бэкендера, который пришёл в разработку промышленных или финансовых систем. Он уверен, что интернет доступен всегда :)
Но, с другой стороны, часто дообучить специалиста оказывается быстрее и эффективнее, чем искать готового.
Бывают и специфические случаи. Я однажды искал питониста со знанием плюсов (или наоборот), поскольку нужно было переписать развесистых и сильно асинхронный код с питона на C++.
Как выяснилось, это исключительно редкие звери, искал три месяца, что было неожиданно, т.к. сам я - универсал с тучей языков и технологий в бэкграунде.
Размазывание логики в проектах, состоящих не из одного скрипта/бинарника, практически неизбежно. У вас всё равно будет фронт (вебовский или standalone), бэк (возможно, микросервисный) с набором API и БД, не считая промежуточных уровней. В архитектурах с ESB ещё и шина со своей логикой доставки и преобразования данных. Логика на уровне базы данных тут не является чем-то исключительным.
и в комментариях в коде капсом "ЛОГИКА В БД!"
Тут кроме качественного документирования мало что поможет. Должно быть не "логика в БД", а ссылка на документ, где описана логика в БД :)
Ну и живое участие в проекте датабазного разработчика, не совмещённого с должностью DBА экасплуатации (что не редкость).
Это реально, если проект начинается с проектирования, а не со спринта "куда-то в ту сторону".
Вообще-то, современные СУБД имеют мощные средства управления доступом к данным, их просто нужно знать . Ну а архитектура - это не только про красоту концепции, но и про производительность.
Это потому, что, во-первых, работа с локальными данными в нативном формате БД быстрее, чем с сетевыми с парой преобразований по дороге. А, во-вторых, потому, что разработчики СУБД уже потратили энное количество человек-часов на то, чтобы оптимизировать работу с информацией, которая не умещается в оперативную память целиком
Меня как, старого архитектора БД, этот модный подход дико раздражает. "Давайте будем использовать СУБД как Excel и гонять гигабайты между базой и микросервисами просто потому, что не умеем в оптимизацию и хранимые процедуры" :)
Причём, такой паттерн не просто широко используется, но и пропагандируется.
Во-первых, это просто интересно :) LLM и их продукция - сами по себе вполне достойный предмет для исследований.
А во-вторых, полезно на практике выяснять слабые и сильные стороны этого ИНСТРУМЕНТА, который продолжает развиваться. И с результатами работы которого неизбежно придётся сталкиваться чем дальше, тем чаще.
У меня похожая история кончились переходом на Mint и "Gnome здорового человека" aka Cinnamon в 2017 году.
До этого за 20 лет использования линуксов перепробовал почти всё интересное в плане десктопов, от enlightenment-а до unity, компизовским кубиком виндузятников впетатлял :)
Сейчас просто работаю, 90% времени - проектирование, кодинг, работа с LLM и браузер.
Я у нейросетевых питонистов на собесе любил спрашивать про asyncio...
Я у нейросетевых питонистов на собесе любил спрашивать про asyncio...
У меня на питоне несколько больших живых сервисов у разных заказчиков и прототипирование всего протокольного, что потом переписывается на плюсы ради высокой производительности, такой цикл разработки крайне хорошо себя показал :)
Постановка вопроса смешная, на самом деле. Каждый дополнительный язык - это дополнительные возможности. Рискну предположить, что среди дата-сайнтистов пайтон на уровне понимания внутренних механизмов работы знают единицы.
Через HTTPS-прокси pip работает отлично.
Такое впечатление, что в РКН фильтрацией занимаются или криворукие
уроды"специалисты", или недообученный имитатор интеллекта.Только SQL, строго говоря, не язык программирования, а язык запросов. Не путать с pl/SQL, pg/SQL и другими процедурными надстройками СУБД.
Проверил, работает на ядре 5.4.0-216-generic из Linux Mint 20.3 :)
В целом, идея эксплотиа красивая, но лечится выгрузкой модуля.
Никаких угроз :)
ИИ-генерация типовых приложений, безусловно, будет процветать, и каждый желающий сможет с помощью нейросетки создать собственный minesweeper :)
А вот там, где для решения нужно придумывать, ИИ-кодер человеку - не конкурент. Хотя бы просто потому, что для верного решения нужно корректно поставить задачу и проконтролировать результат, что, как правило, требует приличного понимания программирования и общего computer sience.
Я имею значительный успешный опыт использования ИИ-кодеров в режиме "парного программирования" (прикладной и системный софт), но я хорошо понимаю, что именно пишет ИИ и как это проверить и исправить.
Обычно эти уровни означают различия в ответственности и зарплате :)
С другой стороны, разница между специалистом, ведущим специалистом и главным специалистом в госах тоже, в основносм, в записи в трудовой книжке.
Нужно было хорошо понимать асинхронный стек в питоне и в бусте и уметь анализировать довольно навороченный код.
Это общее. Так же хорошо виден код вебовского бэкендера, который пришёл в разработку промышленных или финансовых систем. Он уверен, что интернет доступен всегда :)
Но, с другой стороны, часто дообучить специалиста оказывается быстрее и эффективнее, чем искать готового.
Нейросеть с нейросетью договорится лучше :)
Бывают и специфические случаи. Я однажды искал питониста со знанием плюсов (или наоборот), поскольку нужно было переписать развесистых и сильно асинхронный код с питона на C++.
Как выяснилось, это исключительно редкие звери, искал три месяца, что было неожиданно, т.к. сам я - универсал с тучей языков и технологий в бэкграунде.
Размазывание логики в проектах, состоящих не из одного скрипта/бинарника, практически неизбежно. У вас всё равно будет фронт (вебовский или standalone), бэк (возможно, микросервисный) с набором API и БД, не считая промежуточных уровней. В архитектурах с ESB ещё и шина со своей логикой доставки и преобразования данных. Логика на уровне базы данных тут не является чем-то исключительным.
Тут кроме качественного документирования мало что поможет. Должно быть не "логика в БД", а ссылка на документ, где описана логика в БД :)
Ну и живое участие в проекте датабазного разработчика, не совмещённого с должностью DBА экасплуатации (что не редкость).
Это реально, если проект начинается с проектирования, а не со спринта "куда-то в ту сторону".
Вообще-то, современные СУБД имеют мощные средства управления доступом к данным, их просто нужно знать . Ну а архитектура - это не только про красоту концепции, но и про производительность.
Чем лучше? :)
Это потому, что, во-первых, работа с локальными данными в нативном формате БД быстрее, чем с сетевыми с парой преобразований по дороге. А, во-вторых, потому, что разработчики СУБД уже потратили энное количество человек-часов на то, чтобы оптимизировать работу с информацией, которая не умещается в оперативную память целиком
Меня как, старого архитектора БД, этот модный подход дико раздражает. "Давайте будем использовать СУБД как Excel и гонять гигабайты между базой и микросервисами просто потому, что не умеем в оптимизацию и хранимые процедуры" :)
Причём, такой паттерн не просто широко используется, но и пропагандируется.
Во-первых, это просто интересно :)
LLM и их продукция - сами по себе вполне достойный предмет для исследований.
А во-вторых, полезно на практике выяснять слабые и сильные стороны этого ИНСТРУМЕНТА, который продолжает развиваться. И с результатами работы которого неизбежно придётся сталкиваться чем дальше, тем чаще.
В общем, "utile cum dulci".