Не понял ваш вопрос - я компиляторов не писал (если не считать таковым некоторую поделку, транслирующую некоторые короткие текстовые конструкции в SQL), но я как раз и говорю что без "кожанных" разработчиков индустрия не удержится - развитие языков/фреймворков в том виде как оно сейчас происходит просто остановится, т.к. LLM все равно на чем писать, нет причин что-то улучшать, технически на любом тьюринг-полном языке можно написать что угодно вычислимое
LLM уже сейчас вполне может написать рабочий код на придуманном вами языке без сотен примеров кода, просто по документации.
Рабочий в смысле синтаксически верный? - да, согласен, вот только практика показывает что чем меньше примеров в обучающих данных для конкретного языка тем хуже решения которые предлагает LLM. Попробуйте попросить написать что-нибудь на РЕФАЛ, и посмотрите на качество решения.
Для написания кода самой системы - да, вероятно, но ведь на текущем этапе LLM без обучающих данных ничего не стоят, а новых данных без "кожанных" не будет. Если бы данные не были краеугольным камнем уже сейчас бы LLM писали на ассемблере или прямо в машинных кодах под конкретное железо - код был бы просто несапоставимо быстрее чем то что они пишут на всяких java-python-etc.
Вы, кажется, ни одной статьи сами не написали, почему бы вам не сосредоточиться на написании хоть одной, вместо того чтобы рассказать другим что и как делать?
Например чтобы оценить насколько хорошо оно написано - слов разной степени академичности вокруг качества предлагаемого решения сказано много, а предложение проверить пчм-то вызывает рассуждения о неуместности
да, было года два или больше назад большое обсуждение под статьей, просили тогда возможность сверить скорость отрисовки "по честному" - без кэшей, честные затраты времени на отрисовку, пересказ аргумента почему нельзя как раз оттуда
Когда становится в жизни грустно, я вспоминаю, что сравнить скорость работы рендера для бесконечного скрола из $mol с реализациями из других библиотек нельзя, т.к. у версии из $mol нельзя отключить кэш, т.к. на $mol нельзя говнокодить, и настроение сразу становится чуточку лучше.
Тут кажется все достаточно прозрачно - новый формат номера это новый документ, и работать с ним надо как с другим документом, вы же не будете в одно поле писать и номер паспорта, и, например, номер охотничего билета?
Если мы обсуждаем конкретно паспорта то да, новый формат номера это новый документ, и с моей точки зрения хранить его номер там же где хранятся номера "старых" документов неверно.
Вариант для менее бюрократизированных случае я привел как пример, как в некоторых случаях могут работать с номерами, для основного документа удостоверяющего личность это неприминимо.
если конкретно про паспорта то ни то ни другое - другой формат номера это другой документ
для ситуаций инвентарных номеров и т.п. при смене формата пишут что-то вроде "при указании номера меньшей длины считать номер дополненным нулями слева до <число> знаков"
Возможно в уважаемых фирмах так можно (мне всеже сомнительно, т.к. судя по явно проставляемым ведущим нулям формат предполагает фиксированное число знаков, а эти номера фигурируют как минимум в учетных документах, и при таком подходе все документы содержащие 12345678 после изменения числа знаков оказались неверно заполненными), но как минимум с основным документом удоставеряющим личность это не так - формат его номера закреплен законом также как и, например, данные присутствующие на первой странице. Новый формат номера возможен для нового документа - например "паспорт гражданина РФ 2.0", но если появляется именно новый документ кажется что хранить его номер вместе с номерами другого документа идея сомнительная.
а вы считаете что эти теоретические новые номера корректно хранить вместе со старыми? законом закреплён формат документа, если вводится новый формат - это будет новый закон и новый документ
вы же, наверное, не будете в колонку "номер паспорта гражданина РФ" писать, например, номер удостоверения моряка (хотя это тоже документ удостоверяющий личность)?
честно говоря я его не понял, почему вы думаете что при этом изменении паспорт 0001 и 00001 это будут разные паспорта?
в системах с фиксированным числом разрядов при увеличении числа разрядов всегда делается пересчет - т.е. тот что был 0001 теперь 00001, у вас же система от добавления разряда не становится имеющей различное число знаков
Не понял ваш вопрос - я компиляторов не писал (если не считать таковым некоторую поделку, транслирующую некоторые короткие текстовые конструкции в SQL), но я как раз и говорю что без "кожанных" разработчиков индустрия не удержится - развитие языков/фреймворков в том виде как оно сейчас происходит просто остановится, т.к. LLM все равно на чем писать, нет причин что-то улучшать, технически на любом тьюринг-полном языке можно написать что угодно вычислимое
Рабочий в смысле синтаксически верный? - да, согласен, вот только практика показывает что чем меньше примеров в обучающих данных для конкретного языка тем хуже решения которые предлагает LLM. Попробуйте попросить написать что-нибудь на РЕФАЛ, и посмотрите на качество решения.
Для написания кода самой системы - да, вероятно, но ведь на текущем этапе LLM без обучающих данных ничего не стоят, а новых данных без "кожанных" не будет. Если бы данные не были краеугольным камнем уже сейчас бы LLM писали на ассемблере или прямо в машинных кодах под конкретное железо - код был бы просто несапоставимо быстрее чем то что они пишут на всяких java-python-etc.
А если не будет квалифицированных "кожанных" разработчиков - то кто будет поддерживать эти LLM? Сами LLM?
Только если в части собственной совести
Вы, кажется, ни одной статьи сами не написали, почему бы вам не сосредоточиться на написании хоть одной, вместо того чтобы рассказать другим что и как делать?
Разок внимательно прочитать текст перед тем как публиковать не пробовали?
Например чтобы оценить насколько хорошо оно написано - слов разной степени академичности вокруг качества предлагаемого решения сказано много, а предложение проверить пчм-то вызывает рассуждения о неуместности
да, было года два или больше назад большое обсуждение под статьей, просили тогда возможность сверить скорость отрисовки "по честному" - без кэшей, честные затраты времени на отрисовку, пересказ аргумента почему нельзя как раз оттуда
Спасибо что вы пишете!
Когда становится в жизни грустно, я вспоминаю, что сравнить скорость работы рендера для бесконечного скрола из $mol с реализациями из других библиотек нельзя, т.к. у версии из $mol нельзя отключить кэш, т.к. на $mol нельзя говнокодить, и настроение сразу становится чуточку лучше.
ИИ может и может, но его же надо попросить это сделать
Хотел спросить, а почему вы уверены, что вайбокодеры умеют работать с пакетами?
Тут кажется все достаточно прозрачно - новый формат номера это новый документ, и работать с ним надо как с другим документом, вы же не будете в одно поле писать и номер паспорта, и, например, номер охотничего билета?
Если мы обсуждаем конкретно паспорта то да, новый формат номера это новый документ, и с моей точки зрения хранить его номер там же где хранятся номера "старых" документов неверно.
Вариант для менее бюрократизированных случае я привел как пример, как в некоторых случаях могут работать с номерами, для основного документа удостоверяющего личность это неприминимо.
если конкретно про паспорта то ни то ни другое - другой формат номера это другой документ
для ситуаций инвентарных номеров и т.п. при смене формата пишут что-то вроде "при указании номера меньшей длины считать номер дополненным нулями слева до <число> знаков"
Возможно в уважаемых фирмах так можно (мне всеже сомнительно, т.к. судя по явно проставляемым ведущим нулям формат предполагает фиксированное число знаков, а эти номера фигурируют как минимум в учетных документах, и при таком подходе все документы содержащие 12345678 после изменения числа знаков оказались неверно заполненными), но как минимум с основным документом удоставеряющим личность это не так - формат его номера закреплен законом также как и, например, данные присутствующие на первой странице. Новый формат номера возможен для нового документа - например "паспорт гражданина РФ 2.0", но если появляется именно новый документ кажется что хранить его номер вместе с номерами другого документа идея сомнительная.
а вы считаете что эти теоретические новые номера корректно хранить вместе со старыми? законом закреплён формат документа, если вводится новый формат - это будет новый закон и новый документ
вы же, наверное, не будете в колонку "номер паспорта гражданина РФ" писать, например, номер удостоверения моряка (хотя это тоже документ удостоверяющий личность)?
видимо на ваших собеседованиях размеры типов данных не спрашивают
всё-таки "целочисленный тип" некорректно подменять на integer, в него кажется ни в каком варианте исполнения все возможные 10-значные числа не влезут
так и не придется - серия имеет фиксированное число знаков, если теперь это 5 знаков - ок, значит 0384 теперь 00384
от того что к фиксированной длине добавили разряд формат не стал предполагать вариативность в длине
честно говоря я его не понял, почему вы думаете что при этом изменении паспорт 0001 и 00001 это будут разные паспорта?
в системах с фиксированным числом разрядов при увеличении числа разрядов всегда делается пересчет - т.е. тот что был 0001 теперь 00001, у вас же система от добавления разряда не становится имеющей различное число знаков