И я в половине технического стека этого ничего не понимаю.
IMHO, это потенциально большая проблема. Время разработки уменьшается кардинально, но поиск и исправление ошибок могут слопать экономию и попросить ещё.
LLM в качестве подсказчика по знакомому стеку, всё-таки, безопаснее.
У меня тоже 25+ лет разработки кода и системной архитектуры, с десяток языков в более-менее активном использовании.
Но если присмотреться, заметно ключевое: они не просто позволяют ИИ генерировать код. Они постоянно рефакторят сгенерированный код.
Строго говоря, сейчас это единственно работающий подход к использованию LLM в программиировании. Я в последние два года много экспериментировал с автогенерацией кода под локальные задачи в С, С++, Python и Kotlin, и пришёл у выводу, что описание задач в виде подробных промптов по сложности не особенно отличается от кодинга на вышеупомянутых языках с той разницей, что естественный язык хуже приспособлен для программирования :)
Практически во всех случаях сгенерированный код требовал верификации с помощью ревью и тестов, и часто содержал ошибки, далеко не всегда легко выявляемые младшими членами команды.
Ну, как "пенсионеры"... Три года назад ко мне подкатывали люди с предложением "ты же в детстве на коболе писал, давай возглавишь подразделение по поддержке кобольных финсистем, а то ЖИВЫХ РАЗРАБОВ не осталось".
Всё потому, что пропагандируемый со времён первых массовых книжек от о'Рейли "хороший перловый стиль" - фактически, write only. На перле можно писать понятно, но это некузяво :)))
Мне кажется, это, практически, "строим гитару из лопаты" :)
Я, в своё время, пошёл по пути покупки дешёвого старта aka Squier Bullet, который затем оброс бабичевской машинкой тремоло, звучками DiMarzio и немного другой электроникой и превратился в нежно любимый Fender Catastropher :)
Но суммарная стоимость доработок изрядно превысила стартовый ценник гитары.
Питон отлично программируется и без IDE, в простом текстовом редакторе. Тут особой разницы с баш-скриптингом нет.
В моей практике баш-скрипты чаще используются для автоматизации сборки и деплоймента продуктов, а питоновские - для разнообразного сбора и анализа данных. Стратегически это себя оправдывает :)
Чистый Си очень прост. И глядя на код довольно легко понять, во что примерно он будет развернут.
Ну, это как писать :)
Особенно, с учётом возможностей препроцессора. Реально, на практике астречается много "заумно эффективного" кода, особенно, в программировании микроконтроллеров
Замечу, что высшая математика вполне применима в инженерных дисциплинах, например концепция комплексных чисел сильно облегчает расчёты в электротехнике.
Я охотно использую python для быстрого прототипирования сервисов и систем, но когда речь заходит о продакшен-версиях, многое переписывается на плюсы именно из-за выигрыша в быстродействии и памяти. В итоге, получаем продукт, где верхнеуровневые грабли, в целом, пойманы и ликвидированы, а производительность в разы выше, чем в прототипе.
Что до С в С++, то "портабельный ассемблер" часто удобен, просто требует, как и любой инструмент, грамотного обращения. Например, аккуратных оберток для вызова из плюсов.
Так это не препятствие для подготовленной службы поддержки иностранной разведки. Сначала на собесы ходят кандидаты, задача которых - собрать типовые задания и понять приоритеты. Потом целевой шпион просто прокачивается на эти кейсы :) Но, на самом деле, проверки СБ - совсем другая история.
А вообще, "расколоть" товарища, который не сам написал код, на очном собеседовании как нефиг делать совсем несложно.
Взрослее всего это устроено у Оракла :)
IMHO, это потенциально большая проблема. Время разработки уменьшается кардинально, но поиск и исправление ошибок могут слопать экономию и попросить ещё.
LLM в качестве подсказчика по знакомому стеку, всё-таки, безопаснее.
У меня тоже 25+ лет разработки кода и системной архитектуры, с десяток языков в более-менее активном использовании.
Ну, они как бы не сами дообучаются. Нужно, чтобы команда, ведущая модель, включила соответствующие кейсы в обучающие выборки.
Строго говоря, сейчас это единственно работающий подход к использованию LLM в программиировании. Я в последние два года много экспериментировал с автогенерацией кода под локальные задачи в С, С++, Python и Kotlin, и пришёл у выводу, что описание задач в виде подробных промптов по сложности не особенно отличается от кодинга на вышеупомянутых языках с той разницей, что естественный язык хуже приспособлен для программирования :)
Практически во всех случаях сгенерированный код требовал верификации с помощью ревью и тестов, и часто содержал ошибки, далеко не всегда легко выявляемые младшими членами команды.
Посмотрим, конечно, что будет лет через пять.
Ещё не упомянуты макроассемблеры, которые оптимизирующие компиляторы С в области разработки ПО для микроконтроллеров, фактически, похоронили.
Ну, как "пенсионеры"... Три года назад ко мне подкатывали люди с предложением "ты же в детстве на коболе писал, давай возглавишь подразделение по поддержке кобольных финсистем, а то ЖИВЫХ РАЗРАБОВ не осталось".
Странно, что никто не вспомнил про Пролог. А ведь по-своему уникальный язык
Я на клиппере медицинскую систему писал лет 30 назад
Всё потому, что пропагандируемый со времён первых массовых книжек от о'Рейли "хороший перловый стиль" - фактически, write only. На перле можно писать понятно, но это некузяво :)))
Мне кажется, это, практически, "строим гитару из лопаты" :)
Я, в своё время, пошёл по пути покупки дешёвого старта aka Squier Bullet, который затем оброс бабичевской машинкой тремоло, звучками DiMarzio и немного другой электроникой и превратился в нежно любимый Fender Catastropher :)
Но суммарная стоимость доработок изрядно превысила стартовый ценник гитары.
Питон отлично программируется и без IDE, в простом текстовом редакторе. Тут особой разницы с баш-скриптингом нет.
В моей практике баш-скрипты чаще используются для автоматизации сборки и деплоймента продуктов, а питоновские - для разнообразного сбора и анализа данных. Стратегически это себя оправдывает :)
В 20-м C++ ввели стоковые шаблоны а-ля f-строки в питоне :)
Чистый Си очень прост. И глядя на код довольно легко понять, во что примерно он будет развернут.Ну, это как писать :)
Особенно, с учётом возможностей препроцессора. Реально, на практике астречается много "заумно эффективного" кода, особенно, в программировании микроконтроллеров
Замечу, что высшая математика вполне применима в инженерных дисциплинах, например концепция комплексных чисел сильно облегчает расчёты в электротехнике.
Каждому овощу - свой фрукт :)
Я охотно использую python для быстрого прототипирования сервисов и систем, но когда речь заходит о продакшен-версиях, многое переписывается на плюсы именно из-за выигрыша в быстродействии и памяти. В итоге, получаем продукт, где верхнеуровневые грабли, в целом, пойманы и ликвидированы, а производительность в разы выше, чем в прототипе.
Что до С в С++, то "портабельный ассемблер" часто удобен, просто требует, как и любой инструмент, грамотного обращения. Например, аккуратных оберток для вызова из плюсов.
LOL, мне как-то за технические комментарии в совершено техническом же топике прилетело два минуса с пометками "политика" и "личная неприязнь" :)))
"Я устал, я ухожу" ?
Можно было бы это сделать чуть менее по-хамски.
Линусу, говорящему об исторической памяти, тогда было бы логично выгнать из мейнтейнеров всех шведов, раз уж на то пошло :)
Так это не препятствие для подготовленной службы поддержки иностранной разведки. Сначала на собесы ходят кандидаты, задача которых - собрать типовые задания и понять приоритеты. Потом целевой шпион просто прокачивается на эти кейсы :)
Но, на самом деле, проверки СБ - совсем другая история.
А вообще, "расколоть" товарища, который не сам написал код, на очном собеседовании
как нефиг делатьсовсем несложно.