Ну да, нужно прикручивать статистические анализаторы, в т.ч. ваш PVS - тогда LLM-ка сможет скорректировать код, чтобы было 0% предупреждений. Но станет ли лучше?
потраченные на борьбу с багами памяти в C или C++, оставившие после себя глубокие шрамы, обесценились с появлением Rust
Ну если честно - нет. До сих пор реально C|C++ в топе (TIOBE Index 2 и 3 место) а Rust только на 10 месте... Понятно что мы все в мечтах уже считаем что Rust уделал - но реально пока нет. Остальные ваши языки - это не системные.
Теперь так может каждый - по этому ценность такой информации равна нулю. Когда раньше писал сам и разбирался с нуля сам - лучше в голове держалось. Сейчас вроде и понял, если что не понятно - спросил и вроде понял. Но через пару-тройку месяцев уже как будто это было не с тобой...
Вопрос нужно ставить иначе - а есть ли реальные альтернативы? Т.е. по сути мы ничего не можем сделать против течения реки, согласен или нет - а река течет и мы все как говно в проруби - плывем по общему течению.
Если есть реальные альтернативы как идти против всеобщего тренда, переломить тренд - было бы интересно.
допустимо только в MVP-решениях и относительно простых проектах, не претендующих на что-то значимое
Ваша правда. Для внутренних утилит или скриптов, с легко проверяемым поведением, для MVP-проектов (проверка идеи). Т.е. когда есть четкий API (задан человеком) и критерии приемки, полное прокрытие поведения тестами (тесты дергают API и происходит то что задумано).
Когда нужно качество (быть лучше других, а не просто работать), поддерживаемый код - то надежнее и быстрее руками.
Но! Многие пока об этом не знают, LLM-ки начали активно использовать сравнительно недавно, а некоторые даже не начинали. Пока есть вера в чудо...
Проблема в том, что доведение сгенерированного кода до качества, соответствующего уровню продуктивного контура, занимает ничуть не меньше, а иногда и намного больше времени, чем если бы код писался руками.
Есть выход - отделить архитектуру от реализации. Чел. отвечает за контракты, за архитектуру - и даже не заглядывает что там за страх оно нагенерило. Начнешь заглядывать и делать правильно - весь буст так называемый сойдет на нет.
Тут смотрите в чем вопрос. Если вы клепаете скрипт или утилиту небольшую - буст будет 10000%. Т.е. ранее потратил бы неделю (а при незнании технологии - месяц-два) - а тут сгенерит за 3 часа.
Но! Дьявол как всегда в деталях. Промышленный софт - это не наколенная утилита, это целый отдел разработчиков, которые пишут месяцами а то и годами, системы огромные и сложные. И вот тут начинается пробуксовка. Реально чтобы был буст - нужно хорошо продумать архитектуру, нужна высокая организация - а оно само не возникнет.
Ну да, нужно прикручивать статистические анализаторы, в т.ч. ваш PVS - тогда LLM-ка сможет скорректировать код, чтобы было 0% предупреждений. Но станет ли лучше?
Ну если честно - нет. До сих пор реально C|C++ в топе (TIOBE Index 2 и 3 место) а Rust только на 10 месте... Понятно что мы все в мечтах уже считаем что Rust уделал - но реально пока нет. Остальные ваши языки - это не системные.
Еще бы добавить Lean lang - примеры на нем для школьной. Чтобы за одно двух зайцев убить.
Спасибо за ценную инфу, обычно таким не делятся.
Это что хотят - ограничить самих себя? Или типа ядерного клуба - нам можно а новым нельзя?
Теперь так может каждый - по этому ценность такой информации равна нулю. Когда раньше писал сам и разбирался с нуля сам - лучше в голове держалось. Сейчас вроде и понял, если что не понятно - спросил и вроде понял. Но через пару-тройку месяцев уже как будто это было не с тобой...
Так это же не JS а GLSL.
Готовое, серийное - могут также серийно взломать - и потеряете все пароли. Мало ли - кто там смотрел какой код.
Главное что не начали "стенка на стенку".
Ушла эпоха...
Но для практического использования - нужа поддержка множества паролей.
На Rust перевести сложнее. У меня некий опыт есть.
Отдельный вопрос - код получается рабочим, тесты проходит - но LLM-ка добавляет кучу ненужных оберток и не видит простой путь.
А плагин для браузера не писали, чтобы передать девайсу текущий сайт, куда вводится пароль?
Вопрос нужно ставить иначе - а есть ли реальные альтернативы? Т.е. по сути мы ничего не можем сделать против течения реки, согласен или нет - а река течет и мы все как говно в проруби - плывем по общему течению.
Если есть реальные альтернативы как идти против всеобщего тренда, переломить тренд - было бы интересно.
Согласен, пришел к похожим идеям. Контроль должен быть на физическом уровне - т.е. тупо не должно быть возможности обойти публичные контракты.
А как назвать тех кто не понимают, кто даже ни одного ключевого слова ЯП не знает? А ведь бывает что даже не смотрят на каком ЯП оно пишет.
Все же нужно отдельное название для такого вида деятельности.
Ваша правда. Для внутренних утилит или скриптов, с легко проверяемым поведением, для MVP-проектов (проверка идеи). Т.е. когда есть четкий API (задан человеком) и критерии приемки, полное прокрытие поведения тестами (тесты дергают API и происходит то что задумано).
Когда нужно качество (быть лучше других, а не просто работать), поддерживаемый код - то надежнее и быстрее руками.
Но! Многие пока об этом не знают, LLM-ки начали активно использовать сравнительно недавно, а некоторые даже не начинали. Пока есть вера в чудо...
Есть выход - отделить архитектуру от реализации. Чел. отвечает за контракты, за архитектуру - и даже не заглядывает что там за страх оно нагенерило. Начнешь заглядывать и делать правильно - весь буст так называемый сойдет на нет.
Тут смотрите в чем вопрос. Если вы клепаете скрипт или утилиту небольшую - буст будет 10000%. Т.е. ранее потратил бы неделю (а при незнании технологии - месяц-два) - а тут сгенерит за 3 часа.
Но! Дьявол как всегда в деталях. Промышленный софт - это не наколенная утилита, это целый отдел разработчиков, которые пишут месяцами а то и годами, системы огромные и сложные. И вот тут начинается пробуксовка. Реально чтобы был буст - нужно хорошо продумать архитектуру, нужна высокая организация - а оно само не возникнет.
А каким инструментом, если не секрет?