Если с английским ещё ладно, по нему информации много и когда его учил проблем с приложениями курсами и т.д. не было, то с мало популярныи яп (например сейчас учу румынский) приложения часто отсутствуют, либо содержат много ошибок.
Я по итогу, делаю своё приложение, где хочу совместить приятное с полезным. Фишка его в том, что он работает как лидкод, но для изучения языков. Все задачи построены по языку так, что вам нужно написать алгоритм для решения задачи, не просто слова подставить или выбрать вариант ответа.
Простой пример, в румынском есть спряжение глаголов и прилагательных в зависимости от числа, рода и времени. Есть правила спряжений со своими исключениями. Вам, как программисту, нужно написать функцию, что будет применять в себя слово, род, число и возвращать правильное склонение с учётом исключений. Есть набор юнит тестов (скажем на 500 ассертов) этой функции.
Вы скажете: "да там алгоритм будет на одних if, чего сложного?". Я отвечу что здесь главное не написать идеальный алгоритм O(n), а структурировать у себя а голове все правила, изучаемого языка. Лично мне куда проще запомнить правила, особенно комплексные с исключениями, когда по ним напишу код.
Да и андроид планшет в эту цену с более мощными характеристиками можно спокойно найти. Даже с клавиатурой.
Здесь скорее вопрос не в наивности. Каждый родитель хочет порадовать своё чадо. 50$ не такая большая цена. Если ребенок например сломает "игрушку", то вроде как жаль, но не критично. Так же, это неплохой вариант для семей с небольшим достатком. Думаю народ прекрасно понимает, что покупает и чего особо от таких планшетов не ожидает.)
AI ученый в контексте моченый.) Извините за такой комментарий, но честно, уже надоели эти маркетинговые обещания. Какой смысл в AI ученом, если реальные ученые давно используют нейронки, причём зачастую их пишут самостоятельно под определенные задачи. Llm хорошее подспорье, но создание универсальной системы на её основе. Не знаю насколько это целесообразно. Хотя как система, что сможет корректно объяснять обычным людям сложные научные темы, почему нет. Правда с этим и текущие модели справляются более-менее нормально.
Тоже пришёл к чему-то похожему, только с немного другим подходом.
1) Этап планирования и сбор ТЗ
2) Этап создания архитектуры проекта, желательно с минимальным вовлечением ИИ. Здесь создаю документацию, skills, rules, файлы классов с их описанием и примерным набором критически важных методов/свойств. Устанавливаю все необходимые зависимости, настраиваю хуки, git и рабочие области, пишу предварительные unit тесты, настраиваю CI/CD в общем максимально подготавливаю проект для работы llm, чтобы он мог фокусироваться только на коде, а промпты сводились к описанию задачи.
3) После того, как каркас проекта готов, "отдаю" его в работу бэкграунд агентам. Мой любимый это Codex, т.к. он под каждую задачу создаёт отдельную ветку, а после выполнения делает PR. Это очень удобно. Однако, после перехода кодекс на gpt5, openAI сильно начали душить лимитами, без возможности переключения на более старые версии. В целом способов организовать работу много.
Далее, как у автора, идут итерации разработки с тщательной слежкой и правками того, что там выдала llm.
Описал сумбурно, но думаю смысл понятен. Не то чтобы это какой-то ультимативный подход, скорее один из сотен, который лично мне ближе по душе и который можно изменять, как угодно под разные проекты (везде своя специфика).
Знаете, что самое забавное, по сути ничего не поменялось. Всё что описал автор, я или описано в полноценных методиках/подходах, применимо к обычной ручной разработке. Просто сейчас нейросети требуют для качественной разработки следовать подходам, культуре кода, рекомендациям, паттернам и т.д. которыми многие принебрегали до хайпа нейронок. Если раньше, это был вопрос организации работы в больших командах и банального удобства, то сейчас это технический вопрос. Скорее даже необходимость для адекватной работы с нейронками.
Знаете, что самое забавное в текущей ситуации. HR автоматизируют отсев кандидатов при помощи ИИ. Кандидаты автоматизируют создание релевантных резюме под каждую вакансию. По итогу, одни ИИ пытаются обмануть другие ИИ, а те в свою очередь обойти отсев первых. 😂
По итогу, это даже не клоунада, найм просто сломан и работодатели вернулись к единственному способу отсева, который в данном случае работает - блату.
В такой системе джунам почти нет места (учитывая, что их поджимают нейронки), рынок понемногу охлаждается, что в будущем приведёт к ещё бОльшему дефициту специализированных кадров. Новых подходов в найме не появилось, следовательно, проблема решена не будет.
Касаемо же информации в посте, то он немного запоздал. Всё описанное было актуально году в 2023. Уже тогда llm активно использовали HR в своей работе для отсева кандидатов и уже тогда появились и первые лайфхаки со стороны кандидатов, как нейронку можно обмануть.
Это правда, контроллеры должны быть тонкими. Обычно всю бизнес логику из них выносят в сервисы (как минимум), а оттуда уже "распихивают" на более мелкие классы/модули/и т.д., если сервис разрастается. Опять же зависит от архитекторы, но контроллер бизнес логику содержать не должен.
Для всего остального используют middlewares, validators, паресры, всяческие надстройки для request response и т.д. (зависит от фреймворка или в целом от lifecycle архитектуры проекта).
И приходится заставлять себя вчитываться в то, что выдано.
Я всегда, проверяю весь кол в diff режиме и считаю, что использование нейронок в разработке без git невозможна.
Честно и в отношении пет проектов есть много вопросов. Когда только вышел Codex, я ради эксперимента решил навайбкодить при помощи него игру. После десятка новых фишек и разрастания проекта, я полез уже серьезно в кол и ужаснулся. Там бал такой спагетти код, что даже новички напишут намного лучше. Поэтому работа с нейронками требует немного другого подхода с самого начала работы проекта.
Своими экспериментами я получил более-менее жизнеспособный пайплайн разработки, который бы позволил удобно организовать работу, но честно ответить на главный вопрос: "на долгую дистанцию разработки ИИ экономит время?", однозначный ответ дать не могу. Имхо экономит, но довольно мало.
Хороший посыл, который вроде простой, но многие этого не осознают. Я сам относительно недавно (несколько лет назад) осознал простую истину, что нет вообще никакого смысла гнаться за "крутыми", "модными" архитектурами и стеками в любом проекте.
Действительно, стек, архитектуру, паттерны определяет не мода, а реальная потребность при разработке. Золотые слова, про пример с сайтом на 3.5 пользователя а день. Зачем тратить впустую время и свои же человеко часы, если можно взять для этой задачи Вордпресс и просто сделать сайт без всяких выклбеливаний. Большинству заказчиков в целом всё-равно, как технически реализован их сервис им важно качество, время (ведь от него зависит бюджет проекта) и стабильность работы. Следовательно, нужно всегда планировать, что лучше всего подойдёт для того или иного проекта.
Касаемо кода, то сейчас наблюдаю довольно ироничную ситуацию. С приходом в разработку llm, по сути оказалось, что KISS DRY и часть SOLID, очень любимы нейронками. При этом "красивые", но мудреные подходы они не сильно любят. Почему так, описывать долго, но если коротко, то связано с принципами работы llm и mcp. Так что да, сложные решения нужно использовать тогда, когда в них есть реальная необходимость.
А, точно в C# же куча постоянно живёт и GC глохнет если очень много аллокаций. Эхх, понемногу начинаю, забывать специфику C#.( Надо бы на нём, что-то написать, чтобы обновить в памяти.
Да, вы правы мой код в C#, при очень частых вызовах будет "грузить" GC. Я кстати поэтому упомянул, что помещение условий в массив, не всегда уместна.)
Кстати мой пример, чтобы не грузить GC аллокациями можно, переделав, переместив условия из массивов в обычные методы/функции.
Кстати вы верно подметили, и написали хороший вариант для рефакторинга оригинального примера из статьи, там в целом код, как понял проблемный.
Когда много условий, как в примере, иногда выношу их в отдельные массивы. Переписал код из примера на C#, если что не верно, не ругайте (писал без компилятора под рукой, только попросил нейронку синтаксис поправить), но суть думаю понятна.
Вместо того, чтобы все условия писать в строчки, я их группирую в массивы, по смыслу. После, чего использую any() или другие похожие функции в других языках, чтобы реализовать "или" (если нужно "и" можно использовать all() или ему подобные, либо вообще написать эти функции самому они не то чтобы сложные цикл + условие). Если в исходном условии есть скобки, можно один массив вкладывать в другой.
Плюсы такого подхода? Как по мне, более читаемо, по массивам сразу видно, что именно проверяется, чем когда все условия в куче. Удобнее тестировать, в дебаге видны массивы результатов всех условий. Лично мне, проще вносить изменения в подобные массивы, т.к. точно не нарушу скобки. Если говорить по теме, то с таким подходом можно любые длинные условия развернуть и сгруппировать по смыслу.
Из минусов: any() и подобные функции генерируют больше операций (т.к. под капотом там цикл и условия), однако если мы работаем с фиксированным небольшим набором данных, то нагрузка хоть и увеличивается, но разница нулевая. Опять же, всё зависит от конкретного случая, поэтому и не использую такой подход повсеместно.
Лайв кодинг может помочь проверить скорее не хадр скилы, а как вообще человек кодит. Я с такими требованиями не встречался, но если бы мне поручили провести лайвкодинг, то дал бы простую задачу которую без доп контекста даже топовые нейронки до сих пор решают не верно. Лайвкодинг я бы проводил так: дал бы описание задачи в удобном формате для кандидата и попросил бы её решить с демонстрацией экрана у себя на компьютере в любой удобной для него ide. Причём разрешил бы даже нейронкой или гуглом пользоваться (ведь задачу нейронка решит не верно и кандидату придётся понять где ошибка и доработать её). При этом я бы не сидел, как профессор с троечником на экзамене, а постоянно бы направлял, общался, задавал наводящие вопросы, потому что мне моё время дорого и сидеть по часу молча, я не хочу.
И тут вопрос, а что бы я вообще проверил таким лайвкодингом? А намного больше, чем вы сможете проверить в вашей яндекс web ide с задачкой из литкода.
1) Мне важно было бы увидеть ide человека с которой он работает в привычных условиях (особенно если удаленка). Если человек, говорит, что он мидл-сеньор, но открывая например VSCode, у него нет ни одного плагина и он путается в интерфейсе, то что-то тут не то.
2) Нейронки сейчас используют очень многие, бороться с этим бессмысленно да и зачем? Следовательно, я хочу увидеть как человек пишет промпт, т.к. это важно и влияет напрямую на качество ответа нейронки. Если человек пишет "ну там это напиши чтобы всё работало по красоте вот задача:", то уже понятно, что человек не особо понимает, что хочет видеть в результате.
3) Как и говорил задачи бы брал с подвохом и нейронка в большинстве случаев кандидату выдало не верное решение, следовательно ему придётся показать, как он умеет решать задачи в данной ситуации, когда llm не спасает. Заучить решение задач с лит кода каждый может, а вот решить живой кейс нет.
Как по мне, только такой лайв кодинг имеет смысл и реально хоть что-то может показать. Всё остальное это извиняюсь за выражение дроч ради дрочи.
Твоя ценность — это твоя способность сформулировать задачу и заставить кремний работать на тебя. Это убивает предсказуемость. Больше нет гарантированных треков. Есть только ты и хаос.
Хм, так может, чтобы не было хаоса и была возможность грамотно строить технические промпты с последующей проверкой/доработкой проекта всё же нужны хард скилы из старого мира? 🤔
Да не, бред какой-то пойду дальше писать llm "сделаи код шоб робил красива без ашибак".
Касаемо робототехники, то в большинстве случаев разработка ведётся на C/C++ где по сути всё тоже самое в плане контроля. Особенно на более старых версиях, где иногда за ошибку может например восприниматься лишний пробел в конце файла.
Касаемо паскаля, то был же Delphi например, вполне использовавшийся в энтерпрайзе пока не пришёл веб.
Уже есть. 54-ый с его командой, запихал в tg mini app, часть j2me игр и часть игр с ps1. Они это делают ради хайпа. Это на хабре все знают о wasm и многие тут сами в состоянии сделать такой порт (там кроме фронта на js, ничего кодить особо не нужно), а на других ресурсах, где люди далеки от IT, подобные заголовоки дают хайпа много.
Есть ещё один момент. Вроде как нет ни одного сустава в известной природе (я не биолог могу ошибаться), что мог бы прокручиваться на 360° огромное количество раз подряд. Да, например у сов шея крутится на 360° но они не могут крутить головой, словно лопасти вертолёта.
Мне кажется, построение тел, рез суставы куда более эффективный подход в наших реалиях. Эволюция всегда идёт по принципу: чем проще и эффективней, тем лучше.
Ну я тоже видел в PR конфликты, обычно это происходит если в одной задаче продолжать диалог по доработкам и не уточнить из какой ветки брать информацию. По итогу, он берёт из основной из-за чего появляются конфликты, но сколько их не видел они очень простые и в самом интерфейсе гитхаба фиксятся быстро. Так же, если соблюдать правило 1 задача - 1 запрос к Кодексу, то проблем вообще не возникает.
Пользуюсь им с мая месяца и мне он нравится. Проблем с ним не было, единственное он когда ещё на gpt 3 был, любил писать говнокод, но сейчас такого меньше.
Если с английским ещё ладно, по нему информации много и когда его учил проблем с приложениями курсами и т.д. не было, то с мало популярныи яп (например сейчас учу румынский) приложения часто отсутствуют, либо содержат много ошибок.
Я по итогу, делаю своё приложение, где хочу совместить приятное с полезным. Фишка его в том, что он работает как лидкод, но для изучения языков. Все задачи построены по языку так, что вам нужно написать алгоритм для решения задачи, не просто слова подставить или выбрать вариант ответа.
Простой пример, в румынском есть спряжение глаголов и прилагательных в зависимости от числа, рода и времени. Есть правила спряжений со своими исключениями. Вам, как программисту, нужно написать функцию, что будет применять в себя слово, род, число и возвращать правильное склонение с учётом исключений. Есть набор юнит тестов (скажем на 500 ассертов) этой функции.
Вы скажете: "да там алгоритм будет на одних if, чего сложного?". Я отвечу что здесь главное не написать идеальный алгоритм O(n), а структурировать у себя а голове все правила, изучаемого языка. Лично мне куда проще запомнить правила, особенно комплексные с исключениями, когда по ним напишу код.
Да и андроид планшет в эту цену с более мощными характеристиками можно спокойно найти. Даже с клавиатурой.
Здесь скорее вопрос не в наивности. Каждый родитель хочет порадовать своё чадо. 50$ не такая большая цена. Если ребенок например сломает "игрушку", то вроде как жаль, но не критично. Так же, это неплохой вариант для семей с небольшим достатком. Думаю народ прекрасно понимает, что покупает и чего особо от таких планшетов не ожидает.)
AI ученый в контексте моченый.) Извините за такой комментарий, но честно, уже надоели эти маркетинговые обещания. Какой смысл в AI ученом, если реальные ученые давно используют нейронки, причём зачастую их пишут самостоятельно под определенные задачи. Llm хорошее подспорье, но создание универсальной системы на её основе. Не знаю насколько это целесообразно. Хотя как система, что сможет корректно объяснять обычным людям сложные научные темы, почему нет. Правда с этим и текущие модели справляются более-менее нормально.
Тоже пришёл к чему-то похожему, только с немного другим подходом.
1) Этап планирования и сбор ТЗ
2) Этап создания архитектуры проекта, желательно с минимальным вовлечением ИИ. Здесь создаю документацию, skills, rules, файлы классов с их описанием и примерным набором критически важных методов/свойств. Устанавливаю все необходимые зависимости, настраиваю хуки, git и рабочие области, пишу предварительные unit тесты, настраиваю CI/CD в общем максимально подготавливаю проект для работы llm, чтобы он мог фокусироваться только на коде, а промпты сводились к описанию задачи.
3) После того, как каркас проекта готов, "отдаю" его в работу бэкграунд агентам. Мой любимый это Codex, т.к. он под каждую задачу создаёт отдельную ветку, а после выполнения делает PR. Это очень удобно. Однако, после перехода кодекс на gpt5, openAI сильно начали душить лимитами, без возможности переключения на более старые версии. В целом способов организовать работу много.
Далее, как у автора, идут итерации разработки с тщательной слежкой и правками того, что там выдала llm.
Описал сумбурно, но думаю смысл понятен. Не то чтобы это какой-то ультимативный подход, скорее один из сотен, который лично мне ближе по душе и который можно изменять, как угодно под разные проекты (везде своя специфика).
Знаете, что самое забавное, по сути ничего не поменялось. Всё что описал автор, я или описано в полноценных методиках/подходах, применимо к обычной ручной разработке. Просто сейчас нейросети требуют для качественной разработки следовать подходам, культуре кода, рекомендациям, паттернам и т.д. которыми многие принебрегали до хайпа нейронок. Если раньше, это был вопрос организации работы в больших командах и банального удобства, то сейчас это технический вопрос. Скорее даже необходимость для адекватной работы с нейронками.
Я буду читать точно) И на дтф жду подборки интересных в тех. реализации j2me игр
Знаете, что самое забавное в текущей ситуации. HR автоматизируют отсев кандидатов при помощи ИИ. Кандидаты автоматизируют создание релевантных резюме под каждую вакансию. По итогу, одни ИИ пытаются обмануть другие ИИ, а те в свою очередь обойти отсев первых. 😂
По итогу, это даже не клоунада, найм просто сломан и работодатели вернулись к единственному способу отсева, который в данном случае работает - блату.
В такой системе джунам почти нет места (учитывая, что их поджимают нейронки), рынок понемногу охлаждается, что в будущем приведёт к ещё бОльшему дефициту специализированных кадров. Новых подходов в найме не появилось, следовательно, проблема решена не будет.
Касаемо же информации в посте, то он немного запоздал. Всё описанное было актуально году в 2023. Уже тогда llm активно использовали HR в своей работе для отсева кандидатов и уже тогда появились и первые лайфхаки со стороны кандидатов, как нейронку можно обмануть.
Это правда, контроллеры должны быть тонкими. Обычно всю бизнес логику из них выносят в сервисы (как минимум), а оттуда уже "распихивают" на более мелкие классы/модули/и т.д., если сервис разрастается. Опять же зависит от архитекторы, но контроллер бизнес логику содержать не должен.
Для всего остального используют middlewares, validators, паресры, всяческие надстройки для request response и т.д. (зависит от фреймворка или в целом от lifecycle архитектуры проекта).
Я всегда, проверяю весь кол в diff режиме и считаю, что использование нейронок в разработке без git невозможна.
Честно и в отношении пет проектов есть много вопросов. Когда только вышел Codex, я ради эксперимента решил навайбкодить при помощи него игру. После десятка новых фишек и разрастания проекта, я полез уже серьезно в кол и ужаснулся. Там бал такой спагетти код, что даже новички напишут намного лучше. Поэтому работа с нейронками требует немного другого подхода с самого начала работы проекта.
Своими экспериментами я получил более-менее жизнеспособный пайплайн разработки, который бы позволил удобно организовать работу, но честно ответить на главный вопрос: "на долгую дистанцию разработки ИИ экономит время?", однозначный ответ дать не могу. Имхо экономит, но довольно мало.
Хороший посыл, который вроде простой, но многие этого не осознают. Я сам относительно недавно (несколько лет назад) осознал простую истину, что нет вообще никакого смысла гнаться за "крутыми", "модными" архитектурами и стеками в любом проекте.
Действительно, стек, архитектуру, паттерны определяет не мода, а реальная потребность при разработке. Золотые слова, про пример с сайтом на 3.5 пользователя а день. Зачем тратить впустую время и свои же человеко часы, если можно взять для этой задачи Вордпресс и просто сделать сайт без всяких выклбеливаний. Большинству заказчиков в целом всё-равно, как технически реализован их сервис им важно качество, время (ведь от него зависит бюджет проекта) и стабильность работы. Следовательно, нужно всегда планировать, что лучше всего подойдёт для того или иного проекта.
Касаемо кода, то сейчас наблюдаю довольно ироничную ситуацию. С приходом в разработку llm, по сути оказалось, что KISS DRY и часть SOLID, очень любимы нейронками. При этом "красивые", но мудреные подходы они не сильно любят. Почему так, описывать долго, но если коротко, то связано с принципами работы llm и mcp. Так что да, сложные решения нужно использовать тогда, когда в них есть реальная необходимость.
Можно монолит создавать с учётом возможного перехода на микросервисы. Чтобы потом его без проблем попилить. Хуже от этого не станет)
А, точно в C# же куча постоянно живёт и GC глохнет если очень много аллокаций. Эхх, понемногу начинаю, забывать специфику C#.( Надо бы на нём, что-то написать, чтобы обновить в памяти.
Да, вы правы мой код в C#, при очень частых вызовах будет "грузить" GC. Я кстати поэтому упомянул, что помещение условий в массив, не всегда уместна.)
Кстати мой пример, чтобы не грузить GC аллокациями можно, переделав, переместив условия из массивов в обычные методы/функции.
Кстати вы верно подметили, и написали хороший вариант для рефакторинга оригинального примера из статьи, там в целом код, как понял проблемный.
Когда много условий, как в примере, иногда выношу их в отдельные массивы. Переписал код из примера на C#, если что не верно, не ругайте (писал без компилятора под рукой, только попросил нейронку синтаксис поправить), но суть думаю понятна.
Вместо того, чтобы все условия писать в строчки, я их группирую в массивы, по смыслу.
После, чего использую any() или другие похожие функции в других языках, чтобы реализовать "или" (если нужно "и" можно использовать all() или ему подобные, либо вообще написать эти функции самому они не то чтобы сложные цикл + условие). Если в исходном условии есть скобки, можно один массив вкладывать в другой.
Плюсы такого подхода? Как по мне, более читаемо, по массивам сразу видно, что именно проверяется, чем когда все условия в куче. Удобнее тестировать, в дебаге видны массивы результатов всех условий. Лично мне, проще вносить изменения в подобные массивы, т.к. точно не нарушу скобки. Если говорить по теме, то с таким подходом можно любые длинные условия развернуть и сгруппировать по смыслу.
Из минусов: any() и подобные функции генерируют больше операций (т.к. под капотом там цикл и условия), однако если мы работаем с фиксированным небольшим набором данных, то нагрузка хоть и увеличивается, но разница нулевая. Опять же, всё зависит от конкретного случая, поэтому и не использую такой подход повсеместно.
Да, но видимо есть причина почему не делали SDK на паскале (учитывая популярность языка в своё время).
Лайв кодинг может помочь проверить скорее не хадр скилы, а как вообще человек кодит. Я с такими требованиями не встречался, но если бы мне поручили провести лайвкодинг, то дал бы простую задачу которую без доп контекста даже топовые нейронки до сих пор решают не верно. Лайвкодинг я бы проводил так: дал бы описание задачи в удобном формате для кандидата и попросил бы её решить с демонстрацией экрана у себя на компьютере в любой удобной для него ide. Причём разрешил бы даже нейронкой или гуглом пользоваться (ведь задачу нейронка решит не верно и кандидату придётся понять где ошибка и доработать её). При этом я бы не сидел, как профессор с троечником на экзамене, а постоянно бы направлял, общался, задавал наводящие вопросы, потому что мне моё время дорого и сидеть по часу молча, я не хочу.
И тут вопрос, а что бы я вообще проверил таким лайвкодингом? А намного больше, чем вы сможете проверить в вашей яндекс web ide с задачкой из литкода.
1) Мне важно было бы увидеть ide человека с которой он работает в привычных условиях (особенно если удаленка). Если человек, говорит, что он мидл-сеньор, но открывая например VSCode, у него нет ни одного плагина и он путается в интерфейсе, то что-то тут не то.
2) Нейронки сейчас используют очень многие, бороться с этим бессмысленно да и зачем? Следовательно, я хочу увидеть как человек пишет промпт, т.к. это важно и влияет напрямую на качество ответа нейронки. Если человек пишет "ну там это напиши чтобы всё работало по красоте вот задача:", то уже понятно, что человек не особо понимает, что хочет видеть в результате.
3) Как и говорил задачи бы брал с подвохом и нейронка в большинстве случаев кандидату выдало не верное решение, следовательно ему придётся показать, как он умеет решать задачи в данной ситуации, когда llm не спасает. Заучить решение задач с лит кода каждый может, а вот решить живой кейс нет.
Как по мне, только такой лайв кодинг имеет смысл и реально хоть что-то может показать. Всё остальное это извиняюсь за выражение дроч ради дрочи.
Хм, так может, чтобы не было хаоса и была возможность грамотно строить технические промпты с последующей проверкой/доработкой проекта всё же нужны хард скилы из старого мира? 🤔
Да не, бред какой-то пойду дальше писать llm "сделаи код шоб робил красива без ашибак".
Касаемо робототехники, то в большинстве случаев разработка ведётся на C/C++ где по сути всё тоже самое в плане контроля. Особенно на более старых версиях, где иногда за ошибку может например восприниматься лишний пробел в конце файла.
Касаемо паскаля, то был же Delphi например, вполне использовавшийся в энтерпрайзе пока не пришёл веб.
Уже есть. 54-ый с его командой, запихал в tg mini app, часть j2me игр и часть игр с ps1. Они это делают ради хайпа. Это на хабре все знают о wasm и многие тут сами в состоянии сделать такой порт (там кроме фронта на js, ничего кодить особо не нужно), а на других ресурсах, где люди далеки от IT, подобные заголовоки дают хайпа много.
Есть ещё один момент. Вроде как нет ни одного сустава в известной природе (я не биолог могу ошибаться), что мог бы прокручиваться на 360° огромное количество раз подряд. Да, например у сов шея крутится на 360° но они не могут крутить головой, словно лопасти вертолёта.
Мне кажется, построение тел, рез суставы куда более эффективный подход в наших реалиях. Эволюция всегда идёт по принципу: чем проще и эффективней, тем лучше.
Ну я тоже видел в PR конфликты, обычно это происходит если в одной задаче продолжать диалог по доработкам и не уточнить из какой ветки брать информацию. По итогу, он берёт из основной из-за чего появляются конфликты, но сколько их не видел они очень простые и в самом интерфейсе гитхаба фиксятся быстро. Так же, если соблюдать правило 1 задача - 1 запрос к Кодексу, то проблем вообще не возникает.
Пользуюсь им с мая месяца и мне он нравится. Проблем с ним не было, единственное он когда ещё на gpt 3 был, любил писать говнокод, но сейчас такого меньше.