В таком случае это ваше слово чьего либо еще и я не понимаю почему нужно поверить именно вам.
Можете не верить, а можете попробовать и посмотреть, как оно работает. Понравится — используйте, я же ничего не продаю.
Тут раньше в каждой статье и первых 10 комментариях был тонны аргументов, математики и доказательств.
Это же не техническая и не научная статья, какие доказательства вы хотите. Я статью пометил как “мнение“.
Я вам цитирую ваши же слова которые вы же подтвердили в предыдущем комментарии
Прошу прощения, неправильно понял.
И можно поинтересоваться что именно вы разработали с помощью gpt? У вас в статье вагон бездоказательных тезисов, дайте хотя бы пощупать чтоли великие продукты созданные с помощью ии.
Ничего большого я не писал и редко использую код, сгенеренный LLM. Чаще “гуглю“ через него: пример в этом комментарии.
Пример с `prepared statement` — я начал руками делать, ушло минут 10 на первые 5 кейсов. А кейсов под 400 штук. Попытался настроить автозамену через идею — понял, что затея провальная. С LLM решил за пару часов — и то из-за того, что у нас запрещено использовать тулзы вроде Anthrophic claude code.
Вот пример сгенеренного по формула кода. Мог бы и руками сделать, но проект был срочный и оптимизировал время на всем, на чем мог.
Ну, я, например, не согласен. Я считаю что рутина должны быть давно автоматизирована и забыта.
Ну вот примеры рутины:
Рефакторинг, когда понятно, что делать, и надо в нескольких местах писать предсказуемый код.
Переписывание формата тестов — на другой фреймворк перешли.
Перевод одного ЯП на другой. Не всегда получится воспользоваться тулзой (к слову, я свой переводчик писал, знаю, о чем говорю).
Если вы это рутиной не считаете и думаете, что выполняете сложную и/или творческую работу, то вы ошибаетесь. Таким можно больше не заниматься и не тратить время, освободив себя для задач посложнее.
И снова у вас не верный вывод основанный на неверных предположениях
Тогда объясните, почему вы меня спрашиваете: “что именно вы разработали с помощью gpt“, “пощупать чтоли великие продукты созданные с помощью ии“?
Если вы подумали, что я пропагандирую вайб-кодинг, то это не так. У меня ровно противоположные взгляды. Ценность знаний CS, опыт и навыки построения архитектуры стали важнее, чем были до этого.
Я бы вам порекомендовал до комментирования читать вывод к статье, если вы не читаете всю статью.
Если какая-то подготовка есть, то реально. Или так — можно намного лучше пройти, чем если бы ИИ не помогал. Есть уже браузерные расширения, которые слушают вопросы и показывают всплывашки с подсказками. Есть тулзы, которые распознают алго-задачу и показывают рядом, как ее решать и что говорить.
Как владелец подписок гпт и copilot с первого дня как они появились, могу сказать, что это неправда. Особенно copilot был в разы лучше чем сейчас и последние два года. Сhatgpt давал более сложные и детальные ответы, сейчас всегда пытается упростить решение.
Да также сейчас. Регулярно пытаюсь спросить у чатгпт то, что не смог загуглить за 10 мин, вменяемого ответа не получил ни разу )) А то, что я могу загуглить сам, я загуглю без чатгпт.
Простой пример: вы забыли команду, как “зачекаутить“ файл из другой ветки. Просто забыли, потому что часто не используете.
С гуглом надо будет написать запрос, перейти по ссылке, найти на сранице похожие ответы, понять, что это то, что нужно, и потом уже пробовать.
C LLM спрашиваешь и сразу получаешь команду, которая 100% работает. Ни разу не было, чтобы она дала что-то не так на простой запрос вроде примера выше.
Это наивное утверждение. LLM мне нужна, чтобы экономить время. Читать чужой код несложно, если это перевод написанного тобой кода и там всего один небольшой файл.
Я могу руками протестить, что скрипт работает, проверить его с shellcheck, и пробежаться по коду. Когда знаешь 10 ЯП, почти любой читается, как родной.
Мог бы и сам перевести скрипт на Bash, но это бы заняло больше времени и это скучная рутинная задача.
Если вы обладаете достаточной экспертизой, чтобы понять, что ошибок там нет, то LLM вам не нужна. Даже вредна, т.к. читать чужой код сложнее, чем писать свой. А если не обладаете, то я бы, тем более, не рисковал.
И почему в три наиболее популярных ЯП с динамической типизацией (js, python, php) начали добавлять типы или делать типизированные обёртки?
Я выше писал, js и php — неявная слабая типизация, тут скорее с этим проблемы. Кроме того, в jvm появляются языки с динамической типизацией, вроде Clojure.
От ЯП тоже зависит: если в противовес взять оверинжинерию на Java, как в FizzBuzzEnterpriseEdition, то я бы лучше на Clojure писал.
Ну мы тут вроде подразумеваем выразительные системы типов без культуры нетипизированного оверинжиниринга. Java с её тырпрайз эдишнами не удовлетворяет ни одному из этих пунктов.
Если выбирать между джавой и, не знаю, питоном, то я бы тоже не знаю что выбрал.
Где все постоянно меняется (требования, апи клиентов, бизнес-направления и т.п.), типы будут только мешать.
Наоборот, помогают. Поменял тип в одном месте согласно изменившимся требованиям/апи/етц, и потом просто следуешь за руганью компилятора, даже запускать ничего не надо.
Рефакторить типизированный код — одно удовольствие. Обновлять и поддерживать его — тоже.
It depends. От ЯП тоже зависит: если в противовес взять оверинжинерию на Java, как в FizzBuzzEnterpriseEdition, то я бы лучше на Clojure писал. От типа проекте. Где все постоянно меняется (требования, апи клиентов, бизнес-направления и т.п.), типы будут только мешать.
Т.е. идем на поводу у хренак-хренак-в продакшн, а дальше любтсь оно конем, гори оно огнем?
Это уже ваше дело, что и как делать. Я иногда кложу использую, чтобы быстро отладиться и набросать решение, а потом переписываю на целевой язык. Потому REPL лиспов дает огромное преимущество.
Для проектов, у которых ожидаемо маленький скоуп и нет требований к перформансу тоже удобно кложу использовать.
Подход, поощряющий навалить кучу и выдать ее за инсталляцию как-то, как по мне, плохо совместим с понятием качественного продукта
Я не знаю, какой стек вы ругаете, думая о динамической типизации, но я сам видел как хорошие, так и плохие проекты на Clojure. На Python и JS сам бы не очень хотел писать. До PHP не дотрагивался.
Т.е. идем на поводу у хренак-хренак-в продакшн, а дальше любтсь оно конем, гори оно огнем? Подход, поощряющий навалить кучу и выдать ее за инсталляцию как-то, как по мне, плохо совместим с понятием качественного продукта
Какую задачу решает динамическая типизация? И, повторюсь, если динамическая типизация в этих языках намеренно, то почему все они начали обрастать статическими типами?
C динамической типизацией код пишется быстрее, больше идей можно реализовать. Минусы — в среднем сложнее поддерживать кодовую базу, особенно командой.
Я привел в этом комментарии примеры того, как динамическая типизация дает гибкость.
У меня нет предпочтений в этом плане, если что, я не слепой защитник динамической типизации.
Да, а через (_|_) делается потому, что програзм - это гибкое постиндустриальное производство, для которого требуется следующий экономический строй. Капитализм, то есть жадный алгоритм управления экономикой, не тянет.
Можете не верить, а можете попробовать и посмотреть, как оно работает. Понравится — используйте, я же ничего не продаю.
Это же не техническая и не научная статья, какие доказательства вы хотите. Я статью пометил как “мнение“.
Прошу прощения, неправильно понял.
Ничего большого я не писал и редко использую код, сгенеренный LLM. Чаще “гуглю“ через него: пример в этом комментарии.
Пример с `prepared statement` — я начал руками делать, ушло минут 10 на первые 5 кейсов. А кейсов под 400 штук. Попытался настроить автозамену через идею — понял, что затея провальная. С LLM решил за пару часов — и то из-за того, что у нас запрещено использовать тулзы вроде Anthrophic claude code.
Вот пример сгенеренного по формула кода. Мог бы и руками сделать, но проект был срочный и оптимизировал время на всем, на чем мог.
Ну вот примеры рутины:
Рефакторинг, когда понятно, что делать, и надо в нескольких местах писать предсказуемый код.
Переписывание формата тестов — на другой фреймворк перешли.
Перевод одного ЯП на другой. Не всегда получится воспользоваться тулзой (к слову, я свой переводчик писал, знаю, о чем говорю).
Если вы это рутиной не считаете и думаете, что выполняете сложную и/или творческую работу, то вы ошибаетесь. Таким можно больше не заниматься и не тратить время, освободив себя для задач посложнее.
Тогда объясните, почему вы меня спрашиваете: “что именно вы разработали с помощью gpt“, “пощупать чтоли великие продукты созданные с помощью ии“?
Если вы подумали, что я пропагандирую вайб-кодинг, то это не так. У меня ровно противоположные взгляды. Ценность знаний CS, опыт и навыки построения архитектуры стали важнее, чем были до этого.
Я бы вам порекомендовал до комментирования читать вывод к статье, если вы не читаете всю статью.
Вообще-то сегодня нереально пройти собес с помощью ИИ (по крайней мере в России точно). Собеседователи тоже не идиоты! 😉
Если какая-то подготовка есть, то реально. Или так — можно намного лучше пройти, чем если бы ИИ не помогал. Есть уже браузерные расширения, которые слушают вопросы и показывают всплывашки с подсказками. Есть тулзы, которые распознают алго-задачу и показывают рядом, как ее решать и что говорить.
Как владелец подписок гпт и copilot с первого дня как они появились, могу сказать, что это неправда. Особенно copilot был в разы лучше чем сейчас и последние два года. Сhatgpt давал более сложные и детальные ответы, сейчас всегда пытается упростить решение.
Да также сейчас. Регулярно пытаюсь спросить у чатгпт то, что не смог загуглить за 10 мин, вменяемого ответа не получил ни разу )) А то, что я могу загуглить сам, я загуглю без чатгпт.
Простой пример: вы забыли команду, как “зачекаутить“ файл из другой ветки. Просто забыли, потому что часто не используете.
С гуглом надо будет написать запрос, перейти по ссылке, найти на сранице похожие ответы, понять, что это то, что нужно, и потом уже пробовать.
C LLM спрашиваешь и сразу получаешь команду, которая 100% работает. Ни разу не было, чтобы она дала что-то не так на простой запрос вроде примера выше.
Это наивное утверждение. LLM мне нужна, чтобы экономить время. Читать чужой код несложно, если это перевод написанного тобой кода и там всего один небольшой файл.
Я могу руками протестить, что скрипт работает, проверить его с shellcheck, и пробежаться по коду. Когда знаешь 10 ЯП, почти любой читается, как родной.
Мог бы и сам перевести скрипт на Bash, но это бы заняло больше времени и это скучная рутинная задача.
Если вы обладаете достаточной экспертизой, чтобы понять, что ошибок там нет, то LLM вам не нужна. Даже вредна, т.к. читать чужой код сложнее, чем писать свой. А если не обладаете, то я бы, тем более, не рисковал.
Как знать, факт, что они осилили маркетинг.
Нормальную статическую типизацию и многие разрабочики статически типизированных языков не осилили. Под нормальной я понимаю наличие хотя бы
алгебраических типов
наличие нормально структурной типизации, можно вдобавок к номинативной
нормальный проверяемый статически null либо соответствующие монады вроде Maybe
нормальные функции высшего порядка
Я выше писал, js и php — неявная слабая типизация, тут скорее с этим проблемы. Кроме того, в jvm появляются языки с динамической типизацией, вроде Clojure.
Ну мы тут вроде подразумеваем выразительные системы типов без культуры нетипизированного оверинжиниринга. Java с её тырпрайз эдишнами не удовлетворяет ни одному из этих пунктов.
Если выбирать между джавой и, не знаю, питоном, то я бы тоже не знаю что выбрал.
Наоборот, помогают. Поменял тип в одном месте согласно изменившимся требованиям/апи/етц, и потом просто следуешь за руганью компилятора, даже запускать ничего не надо.
Рефакторить типизированный код — одно удовольствие. Обновлять и поддерживать его — тоже.
It depends. От ЯП тоже зависит: если в противовес взять оверинжинерию на Java, как в FizzBuzzEnterpriseEdition, то я бы лучше на Clojure писал. От типа проекте. Где все постоянно меняется (требования, апи клиентов, бизнес-направления и т.п.), типы будут только мешать.
Первый день и/или первые сто строк. Потом медленнее.
Это уже ваше дело, что и как делать. Я иногда кложу использую, чтобы быстро отладиться и набросать решение, а потом переписываю на целевой язык. Потому REPL лиспов дает огромное преимущество.
Для проектов, у которых ожидаемо маленький скоуп и нет требований к перформансу тоже удобно кложу использовать.
Я не знаю, какой стек вы ругаете, думая о динамической типизации, но я сам видел как хорошие, так и плохие проекты на Clojure. На Python и JS сам бы не очень хотел писать. До PHP не дотрагивался.
Т.е. идем на поводу у хренак-хренак-в продакшн, а дальше любтсь оно конем, гори оно огнем? Подход, поощряющий навалить кучу и выдать ее за инсталляцию как-то, как по мне, плохо совместим с понятием качественного продукта
C динамической типизацией код пишется быстрее, больше идей можно реализовать. Минусы — в среднем сложнее поддерживать кодовую базу, особенно командой.
Я привел в этом комментарии примеры того, как динамическая типизация дает гибкость.
У меня нет предпочтений в этом плане, если что, я не слепой защитник динамической типизации.
Да, а через (_|_) делается потому, что програзм - это гибкое постиндустриальное производство, для которого требуется следующий экономический строй. Капитализм, то есть жадный алгоритм управления экономикой, не тянет.