Ну я веду речь вообще-то про выбор между "написать самому или доверить LLM". LLM вряд ли принципиально лучше джуна или хитрожопого погромиста, а врать умеет даже, пожалуй, поубедительнее последнего. Впрочем, дело вкуса.
И вся прелесть LLM в том, что по идее она сама должна скомбинировать нечто подобное по вашему требованию (промпту).
Вот именно что "по идее". Сгенерированное все равно потом потребуется проверить как минимум на предмет полноты и адекватности, и результат проверки вас вполне может неприятно удивить.
Все на свете тестами не покроешь, а разработка правильных тестов - это тоже своего рода искусство. Как простейший пример для баша - LLM не добавила кавычки "куда надо" (или, наоборот, добавила там где не надо), и в результате на одних данных скрипт будет работать, а на других нет. Нужно иметь представление о потенциальных подводных камнях, и разрабатывать тесты с их учётом, а это означает, что опять же нужны знания в предметной области.
Как минимум лично у меня есть проблема: делать ревью чужого кода мне тяжелее, чем написать аналогичный свой, особенно если манера письма отличается от моей. В случае LLM дело усугубляется их склонностью к галлюцинациям и вранью в стиле "чёрное - это белое". И в любом случае, будь то написание кода или ревью, нужно сначала досконально разобраться в проблеме, а если уж разобрался, то написать код - это чуть ли не самое простое.
Ну скажем так я лично считаю, что говорить плохое - это несколько дешево :) Вот взять и сделать так, чтобы все сказали "вах" и никто не поливал дерьмом - это гораздо сложнее. Я бы даже сказал что это практически невозможно :)
Заодно теперь непонятно почему нужно писать методы классов по старинке:
Хотя бы даже потому, что "по старинке" выглядит банально короче, если нужно написать один метод, а не несколько "почти одинаковых", но с разными квалификаторами. Я даже думаю, что большинство методов и дальше "по старинке" будут писаться :)
Ну, насколько я понимаю, разница в именовании проистекает из принципа работы. template for - это именно шаблон, по которому компилятор перегенерирует "тело цикла" для каждого элемента из указанного списка. А if constexpr сам по себе никакой генерацией кода не занимается, компилятор просто выбирает один из вариантов в соответствии со значением constexpr условия. По-моему достаточно логично.
Шаблоны тут вовсе не при чем. В C и C++ широко практикуется отделение объявления от реализации, и is_copy_constructible далеко не всегда может проверить, что именно делает copy constructor. Вот например без всяких шаблонов:
Как прикажете is_copy_constructible в main.cpp проверять, что именно делает конструктор копии, реализация которого находится в module.cpp? Что, если module.cpp существует только в виде какого-нибудь module.so?
Это здесь при всем. Все ваши претензии по сути к этому и сводятся - мол, "неудобно" брать код под GPL, включать его в свой закрытый продукт и не делиться с сообществом. This is by design.
Опенсорс давно перешел
Если бы не GPL, никакого "опенсорса" в текущем его виде вовсе не было бы. Был бы только закрытый софт, облепленный EULA, как говно - мухами. Вы либо плоховато помните обстоятельства, при которых вообще появились GNU и FSF, либо просто не застали их в силу возраста.
Ну тут кстати есть интересный момент. Сильно сомневаюсь, что разработчики coreutils на расте ну прямо никогда-никогда не заглядывали в исходники соответствующих GNU Coreutils, хехе.
Ну как же, вот я например хочу использовать в своем приложении sdl2 (или любую другую библиотеку, написанную на C) через например вот такой враппер. Враппер при наличии только go вы может и соберете, а саму sdl2 кто будет собирать?
На понятно что gui приложение ты не соберёшь так, но это другое ограничение другого языка уже.
Таким образом можно собрать только относительно несложное приложение без зависимостей написанных на других языках. А другие языки были, есть и будут есть, потому что серебряных пуль не существует.
Ну собственно на этом можно и закончить :) Шутка (наполовину). А если серьезно - мы же берем случай не хелловорлда, а серьезного приложения с зависимостями, написанными на разных языках. То есть возвращаемся к началу - для "решения проблемы" (человек хочет попробовать новое приложение) ему нужно поставить go, поставить C/C++ компилятор, возможно, растокомпилятор (для зависимостей)... Боюсь, что с таким подходом у вас не получится значительно расширить пользовательскую аудиторию :)
в то время как в других языках эта проблема решена
Это в какой-то степени решено только в языках, которые имеют свой рантайм (типа упоминавшихся вами питона, явы или шарпика), там просто все эти проблемы переложены на рантайм - и опять же, только если у вас нет вызовов каких-то сторонних библиотек через native interface. Говорить же, что эта проблема решена в языке потому что он может статически слинковать бинарь - ну, ИМХО, такое. И опять же, этот статически слинкованный вами бинарь, даже если нет никаких условных плагинов (или вы их не забыли все трудолюбиво найти и добавить в пакет), все равно будет точно так же огребать в винде или макоси от паранойи с подписями, как у вас в статье написано.
Это только в теории так все просто, со сферическим конем в вакууме. На практике же например у используемых вами (возможно, даже не напрямую) библиотек бывают плагины, которые статически просто не линкуются, а подгружаются исключительно динамически (через dlopen() или подобные механизмы). Более того, на разных системах нужны разные плагины в зависимости от... много чего - например, где-то нужен плагин для Xorg протокола, а где-то для Wayland, версия библиотеки, установленная в системе, об этом в курсе, а то, что вы там статически себе прилинковали - нет. Го вам поможет только в наипростейшем случае хелловорлда, что-то чуть более сложное - и вы будете совершенно так же огребать.
Еще раз - я не хочу себе на машине компилятор go (это как минимум, еще раз повторюсь, что если само приложение написано на go, это не значит, что все его зависимости написаны на go) для того чтобы один раз запустить приложение на попробовать. Везде это решается бинарными пакетами, которые я просто скачиваю из некоего стора или хранилища пакетов. Я все еще не понимаю, чем условный go в этом плане лучше чем условный C++. Бинарный пакет есть бинарный пакет, и проблемы его установки никак не зависят от языка на котором он написан.
Поправил, не благодарите.
Ну я веду речь вообще-то про выбор между "написать самому или доверить LLM". LLM вряд ли принципиально лучше джуна или хитрожопого погромиста, а врать умеет даже, пожалуй, поубедительнее последнего. Впрочем, дело вкуса.
Вот именно что "по идее". Сгенерированное все равно потом потребуется проверить как минимум на предмет полноты и адекватности, и результат проверки вас вполне может неприятно удивить.
Все на свете тестами не покроешь, а разработка правильных тестов - это тоже своего рода искусство. Как простейший пример для баша - LLM не добавила кавычки "куда надо" (или, наоборот, добавила там где не надо), и в результате на одних данных скрипт будет работать, а на других нет. Нужно иметь представление о потенциальных подводных камнях, и разрабатывать тесты с их учётом, а это означает, что опять же нужны знания в предметной области.
Как минимум лично у меня есть проблема: делать ревью чужого кода мне тяжелее, чем написать аналогичный свой, особенно если манера письма отличается от моей. В случае LLM дело усугубляется их склонностью к галлюцинациям и вранью в стиле "чёрное - это белое". И в любом случае, будь то написание кода или ревью, нужно сначала досконально разобраться в проблеме, а если уж разобрался, то написать код - это чуть ли не самое простое.
Ну скажем так я лично считаю, что говорить плохое - это несколько дешево :) Вот взять и сделать так, чтобы все сказали "вах" и никто не поливал дерьмом - это гораздо сложнее. Я бы даже сказал что это практически невозможно :)
Хотя бы даже потому, что "по старинке" выглядит банально короче, если нужно написать один метод, а не несколько "почти одинаковых", но с разными квалификаторами. Я даже думаю, что большинство методов и дальше "по старинке" будут писаться :)
Ну, насколько я понимаю, разница в именовании проистекает из принципа работы.
template for- это именно шаблон, по которому компилятор перегенерирует "тело цикла" для каждого элемента из указанного списка. Аif constexprсам по себе никакой генерацией кода не занимается, компилятор просто выбирает один из вариантов в соответствии со значениемconstexprусловия. По-моему достаточно логично.Да вроде нормально взаимодействует. Как и с
returnвнутри себя.Вообще-то нет.
У вас не делается ничего подобного. Вставьте отладочную печать скажем в лямбду и непосредственно перед строкой с
forи убедитесь.Шаблоны тут вовсе не при чем. В C и C++ широко практикуется отделение объявления от реализации, и
is_copy_constructibleдалеко не всегда может проверить, что именно делает copy constructor. Вот например без всяких шаблонов:Как прикажете
is_copy_constructibleвmain.cppпроверять, что именно делает конструктор копии, реализация которого находится вmodule.cpp? Что, еслиmodule.cppсуществует только в виде какого-нибудьmodule.so?Это здесь при всем. Все ваши претензии по сути к этому и сводятся - мол, "неудобно" брать код под GPL, включать его в свой закрытый продукт и не делиться с сообществом. This is by design.
Если бы не GPL, никакого "опенсорса" в текущем его виде вовсе не было бы. Был бы только закрытый софт, облепленный EULA, как говно - мухами. Вы либо плоховато помните обстоятельства, при которых вообще появились GNU и FSF, либо просто не застали их в силу возраста.
Теоретически можно, а практически наверняка заглядывали.
Ну тут кстати есть интересный момент. Сильно сомневаюсь, что разработчики coreutils на расте ну прямо никогда-никогда не заглядывали в исходники соответствующих GNU Coreutils, хехе.
Буханка-троллейбус.жпг
Ну как же, вот я например хочу использовать в своем приложении sdl2 (или любую другую библиотеку, написанную на C) через например вот такой враппер. Враппер при наличии только go вы может и соберете, а саму sdl2 кто будет собирать?
Таким образом можно собрать только относительно несложное приложение без зависимостей написанных на других языках. А другие языки были, есть и будут есть, потому что серебряных пуль не существует.
Ну собственно на этом можно и закончить :) Шутка (наполовину). А если серьезно - мы же берем случай не хелловорлда, а серьезного приложения с зависимостями, написанными на разных языках. То есть возвращаемся к началу - для "решения проблемы" (человек хочет попробовать новое приложение) ему нужно поставить go, поставить C/C++ компилятор, возможно, растокомпилятор (для зависимостей)... Боюсь, что с таким подходом у вас не получится значительно расширить пользовательскую аудиторию :)
Это в какой-то степени решено только в языках, которые имеют свой рантайм (типа упоминавшихся вами питона, явы или шарпика), там просто все эти проблемы переложены на рантайм - и опять же, только если у вас нет вызовов каких-то сторонних библиотек через native interface. Говорить же, что эта проблема решена в языке потому что он может статически слинковать бинарь - ну, ИМХО, такое. И опять же, этот статически слинкованный вами бинарь, даже если нет никаких условных плагинов (или вы их не забыли все трудолюбиво найти и добавить в пакет), все равно будет точно так же огребать в винде или макоси от паранойи с подписями, как у вас в статье написано.
Это только в теории так все просто, со сферическим конем в вакууме. На практике же например у используемых вами (возможно, даже не напрямую) библиотек бывают плагины, которые статически просто не линкуются, а подгружаются исключительно динамически (через
dlopen()или подобные механизмы). Более того, на разных системах нужны разные плагины в зависимости от... много чего - например, где-то нужен плагин для Xorg протокола, а где-то для Wayland, версия библиотеки, установленная в системе, об этом в курсе, а то, что вы там статически себе прилинковали - нет. Го вам поможет только в наипростейшем случае хелловорлда, что-то чуть более сложное - и вы будете совершенно так же огребать.Еще раз - я не хочу себе на машине компилятор go (это как минимум, еще раз повторюсь, что если само приложение написано на go, это не значит, что все его зависимости написаны на go) для того чтобы один раз запустить приложение на попробовать. Везде это решается бинарными пакетами, которые я просто скачиваю из некоего стора или хранилища пакетов. Я все еще не понимаю, чем условный go в этом плане лучше чем условный C++. Бинарный пакет есть бинарный пакет, и проблемы его установки никак не зависят от языка на котором он написан.