ООП и ФП не взаимоисключают друг друга. У ФП есть фундаментальный недостаток - это производительность: требование иммутабельности и чистых функций, из-за которых больше операций с памятью, больше нагрузки на GC. Особенно это актуально в JS, т.к. там нет важных оптимизаций, которые добавляют в чисто функциональные языки. ФП может быть красивым, лаконичным и гибким, но если написать тот же код в императивном стиле, он будет работать быстрее, просто потому что так работает сам процессор. Поэтому в случаях когда требуется высокая производительность, лучше писать код напрямую для процессора (обычные циклы, точечные изменения в памяти, отсутствие рекурсивных вызовов), чем гадать как он будет работать после компиляции функциональных структур. Кроме того на ФП сложно писать уникальные вещи похожие на Set/Map, сортировку, обертку над REST API. Можно конечно напрячь свои математические мозги и сделать это, но зачем городить сложностей? Это нарушает принцип KISS, проще и понятнее для всех написать такие вещи в императивном стиле. Поэтому я считаю лучшим вариантом объединение всех 3-х парадигм: структурной, ООП и функциональной. Для каждой найдутся случаи, когда они наиболее просты и эффективны. JS, к счастью, позволяет писать код во всех трех парадигмах.
Я сам стараюсь избегать ООП в JS, но все равно есть много случаев, когда ООП эффективен. Например, когда интерфейс инструмента предполагает наличие нескольких методов, и могут быть разные реализации, удобнее создавать классы под каждую реализацию, а не множество функций.
Неверно. Не просто кусочков менее сложного кода, а специально подобранного кода. Это напоминает легенду об инженере, стукнувшим по котлу, и запросившим за это 10 тысяч долларов. 1$ чтобы стукнуть, и 9999$ чтобы понять куда именно стукнуть. В программировании тоже самое: нужно понять от архитектуры до мелочей какой код, когда и где писать. А LLM наверное и правда видит проект как кучу кода.
Т.е. если человек закончит курсы управления LLM, то LLM станет для него сравнимым по предсказуемости с автомобилем, и он будет решать в предсказуемые сроки 99% специально подобранных для LLM задач?
Я использую только TypeScript практически везде в JS разработке, кроме очень простых вещей типа скриптов. Он дает массу преимуществ, которыми глупо не пользоваться. TypeScript добавляет сложности в проект, но здесь нужно задать вопрос: окупается ли эта сложность? Для меня, если проект больше нескольких сотен строк кода, это окупается. А при разработке чего-то сложного я начинаю с типов, это для меня необходимый этап проектирования.
DI у меня больше похож на derived из svelte, никаких классов, декораций и прочих сложностей пришедших из ООП языков. Вообще, то что придумали в svelte для реактивности - это наверное лучшее, что можно было придумать в рамках стандартного JS, в плане скорости и гибкости, если конечно не ломать сам язык, вводя дополнительные компиляторы.
В FSD несколько слоев, и нужно вручную распределять код по ним, а при любой нестандартной ситуации хвататься за волосы и думать куда впихнуть код или как все переделать так, чтобы не пришлось больше переделывать. FSD подходит только для небольших проектов. DI позволяет сделать только два слоя: слой инъекций и слой фич. Получается, что фичи не зависят от фич вообще, а зависят только от инъекций. Фичи можно объединять в списки (коллекции), из коллекций фич складывать приложения. Граф зависимостей формирует DI; это дает небольшую задержку при запуске приложения, но окупается скоростью разработки и огромной гибкостью.
Автомобиль - это очень хорошо контролируемый и прогнозируемый инструмент. Вот выйдите к оживленному перекрестку, постойте там час и не увидите ни одной аварии. И представьте что было бы если бы ИИ управлялся людьми посредством LLM. Ну и практически все люди доезжают куда хотели на автомобиле. Об LLM такого не скажешь.
Понятия не имею сколько часов. Если начинать со взлета ChatGPT 2023-06-01, исключить мелкие проекты и вайбкодинг, то столько добавленных/удаленных строк: git diff --shortstat "main@{2023-06-01}" "main@{2026-01-01}" 1716 files changed, 101421 insertions(+), 48094 deletions(-)
Стек в этот период времени: svelte-kit, typescript, к ним прилагается еще несколько десятков библиотек и своих инструментов Архитектура была FSD, потом сделал свою с Dependency Injection Библиотека компонентов своя IDE: WebStorm ИИ инструменты в основном эти: Claude chat, Claude Code, Gemini CLI, GitHub copilot
Я как только не пробовал заставить его писать нормальные комменты, он все равно не понимает что важно, а что нет. Видимо для этого понимания нужны мозги. Но создавать видимость он умеет хорошо. Он и переформулирует часто криво, искажая смысл, удаляя важные нюансы, добавляя мусор. Он разве что идеи новых формулировок может предложить. Нужно с ним вместе по коду ходить и комментировать его, используя его как генератор идей и для поиска неочевидных мест в коде. А ТЗ кстати не охватывает все нюансы реализации.
Ну хотя бы мысленное моделирование и прогнозирование. ИИ для этого нужно писать тонны текста, в котором он сам запутается, а у человека это происходит за секунды. Программист кстати не думает текстами, потому что это крайне не эффективно в сложных задачах, включающих много нюансов, он думает мысленными образами.
Я основываюсь на том как ИИ выполняет простые задачи, типа: вот список правил написания качественного кода, вот документация по архитектуре, вот идеальные примеры кода, напиши теперь хотя бы одну функцию качественно. Даже с этим не справляется, мусорит, нарушает правила, радостно ломает код рефакторингом. О чем то более сложном и речи не стояло. Чтобы заставить его работать с приемлемым результатом в одной задаче, ему приходится столько всего объяснять, что быстрее самому все написать. И оказалось, что идеальных правил недостаточно, нужны мозги, т.к. мелочей в каждой задачах много, которые очевидны даже для джуна, а для ИИ их приходится разжевывать. А если вообще не писать код и все отдать ИИ и делать только ревью краем глаза, то эти мелочи не заметит никто, ни ИИ, ни разработчик, а потом окажется, что чтобы их исправить, нужно половину проекта переписывать.
Я уже заметил как "поумнел" Claude 4, по впечатлениям версия 3.7 была умнее. Специально пару тестов сделал, чтобы сравнить их. Claude 4 оказался хуже OpenAI, Gemini и Grok. Есть впечатление, что Антропик обучал новую модель на результатах предыдущей. Качество кода упало, мусора стало больше, зато код стал работать чаще, поэтому и по бенчмаркам кажется, что 4.5 стала умнее. Как по мне, так лучше качественная программа, которую можно развивать, чем "работает не трогай".
Значит вы не поняли мою статью. Я писал не о том, что я разочарован в ИИ, а о том что сейчас есть тренд на активное использование ИИ, и разработчиков вынуждают нырять с головой в это болото, хотят они этого или нет. И работа в итоге стала сложнее из-за ИИ, а точнее из-за отношения людей к его использованию.
Я пользовался всем: Cursor и Gemini CLI немного, Claude Code очень много, и всеми популярными ИИ чатами. Я писал очень много инструкций и документаций в попытках заставить ИИ писать качественный код, или хотя бы частично качественный, чтобы я мог за ним подправить пару мелочей, как это было с джуниор разработчиками. У меня была идея-фикс сделать из ИИ подобие джуниор разработчика, я опробовал все идеи, которые приходили в голову, и не вышло. ИИ слишком тупой для самостоятельного программирования. В итоге оказалось, что быстрее и надежнее писать код самому.
Еще по моим впечатлениям проблема не в качестве модели. Я думаю предел развития LLM уже достигнут, он может и станет в будущем раза в 2-3 умнее, а нужно даже не в 100 раз, а совершенно другая модель, не комбинатор шаблонов, а что-то реально думающее.
А что такой человек делает в IT? Я говорил от джунах, а не об идиотах. У меня был опыт введения в проект двух джунов, это просто гении в сравнении с ИИ. Мне приходилось их контролировать и исправлять код за ними, но это не сравнимо с тем мусором, который генерирует ИИ. У меня не было опыта работы с людьми с IQ 75, но по моим впечатлениям ИИ по уровню здравомыслия где-то на уровне идиота и ниже, если конечно здравый смысл не заложен в самих шаблонах, на которых его обучали.
Компиляторы написаны людьми, они предсказуемы и миллион раз отлажены. ИИ непредсказуем, не следует всем инструкциям, допускает много ошибок, вносит много мусора. Если заставить ИИ отлаживать и дорабатывать им же написанный код код, он будет вносить еще больше мусора и новые ошибки, и может забыть о предыдущих инструкциях. ИИ нельзя называть новым уровнем программирования, т.к. для этого ИИ как минимум должен очень точно выполнять все инструкции, ничего не игнорировать и не искажать.
Человек должен по-другому управлять этим инструментом = Нет способа заставить ИИ думать над каждой мелочью в процессе написания кода. Кто-то должен продумать все эти мелочи и записать их в ТЗ. А многие важные вещи всплывают только во время написания и продумывания кода. И не факт еще, что ИИ все пункты ТЗ правильно выполнит и не исказит. А если их слишком много, он часть из них проигнорирует.
для создания комментов к коммитам = ИИ и это делает плохо. В комментах должен быть смысл, а ИИ формально перечисляет, что изменилось, т.е. тоже мусорит. ИИ и здесь нужно обучать, и потом самому исправлять эти комменты. Если речь о вайбкодинге, то там людям вообще на все плевать, сойдут какие угодно комменты, и с таким кодом потом невозможно работать.
очень активное участие человека во всех процессах разработки = я имел ввиду именно самому писать код, самому писать комменты, документации, тесты, при поддержке ИИ, а не используя ИИ как замену во всех этих задачах.
решение "делать ли приложение из мусора" принимают не инженеры, а менеджеры
= но советуются то они с инженерами или нет? нельзя же принимать важные решения без экспертных знаний, которыми менеджеры здесь не обладают
"работает же"
= а потом выявится неприятный баг или понадобится новая фича, а в этом говнокоде уже мало кто разберется, включая GPT. Можно нанять опытного программиста, но кто из опытных за это возьмется, за обычную зарплату? Я не возьмусь, я не работаю с ужасным кодом, я уже наступал на эти грабли. Или попрошу зарплату в 2-3 раза выше за такую работу. Инженер об этом знает, а менеджеры - нет. Хороший менеджер скорее обратится к инженеру за советом в такого рода решениях, потому что инженер - эксперт в написании и поддержке приложений, а менеджер - нет.
Многое из того, что было предсказано без наличия реального опыта не сбылось, и многое превзошло ожидания. Из этого мы можем только сделать вывод, что такие события невозможно предсказать без реального опыта. Никто не знает. что необходимо для создания AGI, и сколько времени на это потребуется, т.к. еще нет опыта создания AGI.
ООП и ФП не взаимоисключают друг друга. У ФП есть фундаментальный недостаток - это производительность: требование иммутабельности и чистых функций, из-за которых больше операций с памятью, больше нагрузки на GC. Особенно это актуально в JS, т.к. там нет важных оптимизаций, которые добавляют в чисто функциональные языки. ФП может быть красивым, лаконичным и гибким, но если написать тот же код в императивном стиле, он будет работать быстрее, просто потому что так работает сам процессор. Поэтому в случаях когда требуется высокая производительность, лучше писать код напрямую для процессора (обычные циклы, точечные изменения в памяти, отсутствие рекурсивных вызовов), чем гадать как он будет работать после компиляции функциональных структур. Кроме того на ФП сложно писать уникальные вещи похожие на Set/Map, сортировку, обертку над REST API. Можно конечно напрячь свои математические мозги и сделать это, но зачем городить сложностей? Это нарушает принцип KISS, проще и понятнее для всех написать такие вещи в императивном стиле.
Поэтому я считаю лучшим вариантом объединение всех 3-х парадигм: структурной, ООП и функциональной. Для каждой найдутся случаи, когда они наиболее просты и эффективны. JS, к счастью, позволяет писать код во всех трех парадигмах.
Я сам стараюсь избегать ООП в JS, но все равно есть много случаев, когда ООП эффективен. Например, когда интерфейс инструмента предполагает наличие нескольких методов, и могут быть разные реализации, удобнее создавать классы под каждую реализацию, а не множество функций.
Неверно. Не просто кусочков менее сложного кода, а специально подобранного кода.
Это напоминает легенду об инженере, стукнувшим по котлу, и запросившим за это 10 тысяч долларов. 1$ чтобы стукнуть, и 9999$ чтобы понять куда именно стукнуть.
В программировании тоже самое: нужно понять от архитектуры до мелочей какой код, когда и где писать. А LLM наверное и правда видит проект как кучу кода.
Т.е. если человек закончит курсы управления LLM, то LLM станет для него сравнимым по предсказуемости с автомобилем, и он будет решать в предсказуемые сроки 99% специально подобранных для LLM задач?
Я использую только TypeScript практически везде в JS разработке, кроме очень простых вещей типа скриптов. Он дает массу преимуществ, которыми глупо не пользоваться. TypeScript добавляет сложности в проект, но здесь нужно задать вопрос: окупается ли эта сложность? Для меня, если проект больше нескольких сотен строк кода, это окупается. А при разработке чего-то сложного я начинаю с типов, это для меня необходимый этап проектирования.
DI у меня больше похож на derived из svelte, никаких классов, декораций и прочих сложностей пришедших из ООП языков. Вообще, то что придумали в svelte для реактивности - это наверное лучшее, что можно было придумать в рамках стандартного JS, в плане скорости и гибкости, если конечно не ломать сам язык, вводя дополнительные компиляторы.
В FSD несколько слоев, и нужно вручную распределять код по ним, а при любой нестандартной ситуации хвататься за волосы и думать куда впихнуть код или как все переделать так, чтобы не пришлось больше переделывать. FSD подходит только для небольших проектов.
DI позволяет сделать только два слоя: слой инъекций и слой фич. Получается, что фичи не зависят от фич вообще, а зависят только от инъекций. Фичи можно объединять в списки (коллекции), из коллекций фич складывать приложения. Граф зависимостей формирует DI; это дает небольшую задержку при запуске приложения, но окупается скоростью разработки и огромной гибкостью.
Автомобиль - это очень хорошо контролируемый и прогнозируемый инструмент. Вот выйдите к оживленному перекрестку, постойте там час и не увидите ни одной аварии. И представьте что было бы если бы ИИ управлялся людьми посредством LLM. Ну и практически все люди доезжают куда хотели на автомобиле. Об LLM такого не скажешь.
Понятия не имею сколько часов.
Если начинать со взлета ChatGPT 2023-06-01, исключить мелкие проекты и вайбкодинг, то столько добавленных/удаленных строк:
git diff --shortstat "main@{2023-06-01}" "main@{2026-01-01}"
1716 files changed, 101421 insertions(+), 48094 deletions(-)
Стек в этот период времени:
svelte-kit, typescript, к ним прилагается еще несколько десятков библиотек и своих инструментов
Архитектура была FSD, потом сделал свою с Dependency Injection
Библиотека компонентов своя
IDE: WebStorm
ИИ инструменты в основном эти: Claude chat, Claude Code, Gemini CLI, GitHub copilot
Я как только не пробовал заставить его писать нормальные комменты, он все равно не понимает что важно, а что нет. Видимо для этого понимания нужны мозги. Но создавать видимость он умеет хорошо.
Он и переформулирует часто криво, искажая смысл, удаляя важные нюансы, добавляя мусор. Он разве что идеи новых формулировок может предложить. Нужно с ним вместе по коду ходить и комментировать его, используя его как генератор идей и для поиска неочевидных мест в коде.
А ТЗ кстати не охватывает все нюансы реализации.
Ну хотя бы мысленное моделирование и прогнозирование. ИИ для этого нужно писать тонны текста, в котором он сам запутается, а у человека это происходит за секунды. Программист кстати не думает текстами, потому что это крайне не эффективно в сложных задачах, включающих много нюансов, он думает мысленными образами.
Я основываюсь на том как ИИ выполняет простые задачи, типа: вот список правил написания качественного кода, вот документация по архитектуре, вот идеальные примеры кода, напиши теперь хотя бы одну функцию качественно. Даже с этим не справляется, мусорит, нарушает правила, радостно ломает код рефакторингом. О чем то более сложном и речи не стояло. Чтобы заставить его работать с приемлемым результатом в одной задаче, ему приходится столько всего объяснять, что быстрее самому все написать. И оказалось, что идеальных правил недостаточно, нужны мозги, т.к. мелочей в каждой задачах много, которые очевидны даже для джуна, а для ИИ их приходится разжевывать.
А если вообще не писать код и все отдать ИИ и делать только ревью краем глаза, то эти мелочи не заметит никто, ни ИИ, ни разработчик, а потом окажется, что чтобы их исправить, нужно половину проекта переписывать.
Я уже заметил как "поумнел" Claude 4, по впечатлениям версия 3.7 была умнее. Специально пару тестов сделал, чтобы сравнить их. Claude 4 оказался хуже OpenAI, Gemini и Grok. Есть впечатление, что Антропик обучал новую модель на результатах предыдущей. Качество кода упало, мусора стало больше, зато код стал работать чаще, поэтому и по бенчмаркам кажется, что 4.5 стала умнее. Как по мне, так лучше качественная программа, которую можно развивать, чем "работает не трогай".
Значит вы не поняли мою статью. Я писал не о том, что я разочарован в ИИ, а о том что сейчас есть тренд на активное использование ИИ, и разработчиков вынуждают нырять с головой в это болото, хотят они этого или нет. И работа в итоге стала сложнее из-за ИИ, а точнее из-за отношения людей к его использованию.
Я пользовался всем: Cursor и Gemini CLI немного, Claude Code очень много, и всеми популярными ИИ чатами. Я писал очень много инструкций и документаций в попытках заставить ИИ писать качественный код, или хотя бы частично качественный, чтобы я мог за ним подправить пару мелочей, как это было с джуниор разработчиками. У меня была идея-фикс сделать из ИИ подобие джуниор разработчика, я опробовал все идеи, которые приходили в голову, и не вышло. ИИ слишком тупой для самостоятельного программирования. В итоге оказалось, что быстрее и надежнее писать код самому.
Еще по моим впечатлениям проблема не в качестве модели. Я думаю предел развития LLM уже достигнут, он может и станет в будущем раза в 2-3 умнее, а нужно даже не в 100 раз, а совершенно другая модель, не комбинатор шаблонов, а что-то реально думающее.
А что такой человек делает в IT? Я говорил от джунах, а не об идиотах. У меня был опыт введения в проект двух джунов, это просто гении в сравнении с ИИ. Мне приходилось их контролировать и исправлять код за ними, но это не сравнимо с тем мусором, который генерирует ИИ.
У меня не было опыта работы с людьми с IQ 75, но по моим впечатлениям ИИ по уровню здравомыслия где-то на уровне идиота и ниже, если конечно здравый смысл не заложен в самих шаблонах, на которых его обучали.
Компиляторы написаны людьми, они предсказуемы и миллион раз отлажены. ИИ непредсказуем, не следует всем инструкциям, допускает много ошибок, вносит много мусора. Если заставить ИИ отлаживать и дорабатывать им же написанный код код, он будет вносить еще больше мусора и новые ошибки, и может забыть о предыдущих инструкциях.
ИИ нельзя называть новым уровнем программирования, т.к. для этого ИИ как минимум должен очень точно выполнять все инструкции, ничего не игнорировать и не искажать.
Так ведь и есть, в какой проект не ткни - он сложный и уникальный, даже если он внешне кажется простым.
если кто-то захочет за это платить
если бизнес не загнется раньше, из-за очень медленной разработки
= но советуются то они с инженерами или нет? нельзя же принимать важные решения без экспертных знаний, которыми менеджеры здесь не обладают
= а потом выявится неприятный баг или понадобится новая фича, а в этом говнокоде уже мало кто разберется, включая GPT. Можно нанять опытного программиста, но кто из опытных за это возьмется, за обычную зарплату? Я не возьмусь, я не работаю с ужасным кодом, я уже наступал на эти грабли. Или попрошу зарплату в 2-3 раза выше за такую работу.
Инженер об этом знает, а менеджеры - нет. Хороший менеджер скорее обратится к инженеру за советом в такого рода решениях, потому что инженер - эксперт в написании и поддержке приложений, а менеджер - нет.
Многое из того, что было предсказано без наличия реального опыта не сбылось, и многое превзошло ожидания. Из этого мы можем только сделать вывод, что такие события невозможно предсказать без реального опыта. Никто не знает. что необходимо для создания AGI, и сколько времени на это потребуется, т.к. еще нет опыта создания AGI.
== с конвертацией LLM справляется очень хорошо, с этим по-моему никто и не спорит, и такие задачи не требуют инженерного мышления.
== это сложно сделать на человеческом языке, где есть много многозначных или размытых слов