Перфокарты, ассемблер, объектно-ориентированные языки, промпты или почему скоро языки программирования станут не нужны
1. Вступление
Обычно, чтобы понять, куда мы движемся, полезно оглянуться назад и посмотреть, что там, а там, как обычно, лежат ответы на вопросы "почему сегодня всё так устроено" и "что будет дальше".
Смотрите сами, весь прогресс программирования - это история повышения уровня абстракции. Каждый следующий шаг уводил нас все дальше и дальше от железа и ближе к удобству человека (программиста).
Машинные коды - ты должен был знать, какой код у микропроцессора для сложения, где лежит результат, как переключить страницу памяти.
Ассемблер - появились мнемоники, не нужно помнить коды операций микропроцессора, но всё ещё нужно думать про его регистры, стек, сегменты памяти. Где в памяти лежит переменная - это твоя забота.
C - уже можно думать алгоритмами, а не регистрами. Появились функции, типы данных. Но память всё ещё ручная: выделил - не забудь освободить, иначе утечка.
C++ - добавились объекты и полиморфизм, можно писать более крупными блоками. Но память - всё ещё твоя головная боль, хотя уже появились умные указатели.
Java/C# - пришла виртуальная машина, со сборщиком мусора. Можно вообще забыть про ручное управление памятью. Не думаешь, где объект лежит, ты просто создаёшь и работаешь.
Python/JavaScript/1С - уже не просто не думаешь про память, ты не думаешь про типы. Всё динамическое, гибкое, и все прощающее. Можно быстро набросать нужное решение, не заботясь о строгости.
Сейчас в эпоху развития ИИ мы на пороге следующего шага, но и он, мне кажется, будет НЕ последним в этой цепочке.
2. История из 90-х
Середина 90-х я учусь в университете. Наш преподаватель по дискретной математики собрал группу ребят, в которую попал и я, уж не знаю, чем он руководствовался при выборе, но тем не менее. Оказалось, что он собирал себе проектную группу для адаптации языка FORTH под новую тогда x386 архитектуру. Тогда он сумел нас заразить не только элегантностью своего предмета "Дискретная математика", но и языком FORTH, и все ребята, кого он тогда выбрал, остались в этой группе разработки до конца своего обучения.
Интересная особенность FORTH - это язык, который в основном написан на самом себе. Только ядро (базовые слова) реализовано на ассемблере - примитивы для чтения с клавиатуры, вывода на экран, работы с памятью. Всё остальное - написано на самом же языке FORTH.
Мы разделились. Кто-то из нас писал ядро, работающее в защищенном режиме микропроцессора, на ассемблере. В то время у нас была одна единственная книга про защищенный режим микропроцессора x386, выданную нам преподавателем, которую реально зачитали практически до дыр. Другие ребята писали прикладные слова для прикладного уровня языка. Мне же досталась очень объемная задача, это написание среды разработки, по типу, как тогда выглядела среда разработки борландовского Паскаля, с менюшками, окошками, многооконным редактором и отладчиком. Я сильно вдохновился этой идее и начал ее реализовывать, а впоследствии по этой теме я и защищал свой диплом.
История про текстовый редактор для моей среды разработки
Помню, в самом начале, преподаватель поставил мне задачу - подумать, как можно реализовать работу с большим текстом в моей среде разработки. Чтобы можно было вводить символы, вставлять в середину, в начало, в конец. И главное - чтобы всё работало без задержек, независимо от того, 100 символов в тексте или 100 тысяч.
Я пошёл думать. Тогда интернета не было, книжек умных по этой теме, тоже не дали - только собственная голова. День думаю, два думаю... ничего нормально не придумал. Казалось, что любое решение будет тормозить, если текст будет большой.
На третий день руководитель рассказал алгоритм, как это должно работать, и всё оказалось гениально простым.
Технология "Два стека"
Первый стек - текст до курсора.
Второй стек - текст после курсора.
Курсор - это граница между ними.
Хочешь подвинуть курсор влево на один символ? Берёшь символ из первого стека и перекладываешь во второй.
Вправо? Берёшь из второго, кладёшь в первый.
Вводишь новый символ - просто кладёшь его в первый стек.
Нажал Backspace - убрал символ из первого стека.
Вставка текста из буфера? Достаточно переложить символы из буфера в первый стек. И неважно, сколько их - сто или сто тысяч.
И никаких сдвигов массива. Никаких перестроений строки. Никаких тормозов.
Всё работает с одинаковой скоростью при любом размере текста. Потому что операция всегда одна - переложить символ из стека в стек. Стек - это просто вершина, туда класть и забирать можно мгновенно.
Это было красиво и настолько просто, что я тогда даже расстроился, что сам до этого не додумался.
Почему я так подробно разобрал эту технологию сейчас? Я хотел показать, что даже когда ИИ заменит синтаксис, фундаментальные алгоритмы никуда не денутся. Архитектору будущего не нужно будет помнить, как объявить массив в 1С или Python, но ему жизненно необходимо понимать, почему в данной задаче решение с двумя стеками лучше, чем сдвиг массива. ИИ может сгенерировать байт-код для обоих вариантов, но только человек-архитектор сможет оценить элегантность и эффективность этого решения в контексте всей системы.
Мое вдохновение и энтузиазм в то время просто зашкаливал. Помню, как после лекции по Машине Тьюринга я пришел домой, сел за свой ZX Spectrum и на встроенном Бейсике набросал программу, которая была полноценной эмуляцией этой машины. Она честно двигала виртуальную ленту, читала символы и выполняла команды согласно таблице переходов. Для меня тогда это было маленьким чудом: я увидел на практике, что любую сложную задачу можно свести к набору простейших операций. Именно тогда пришло понимание, что программа - это не просто текст, это логический механизм.
К чему все эти воспоминания? Тогда программист должен был знать железо, понимать и создавать алгоритмы. Вот реально знать: как переключать страницы памяти, прерывания микропроцессора, прерывания биоса, защищенный режим микропроцессора и т.д. Даже когда ты писал прикладные слова на FORTH, ты понимал, что под капотом - код, который дергает порты, вызывает то или иное прерывание из биос. Другого способа общаться с машиной просто не было.
Конечно тогда уже были и C и C++, но для нас в середине 90-х FORTH был способом залезть внутрь и понять, как всё устроено с нуля, а потом пришли Java, C#, Python, 1С и каждый новый язык уводил нас от железа все дальше и дальше.
3. Наше настоящее, переход от чата к агентам
Сейчас мы в эпохе, когда можно просто написать в чат "напиши алгоритм", "сделай запрос", кинуть туда процедуру и попросить что-то исправить и получить код. Правда, он не всегда может рабочий, потому что ИИ ничего не знает о вашей конфигурации. Я раньше именно так и делал. И казалось, что это круто, когда ИИ за тебя пишет код.
Но недавно наткнулся на Инфостарте, на разработку Сергея (Prepod2003) - это MCP-сервер для EDT, который позволяет ИИ напрямую работать с конфигурацией 1С. Для меня открылся вообще другой уровень.
Я установил в очередной (уже в третий раз) EDT и начал в нем разбираться, скачал плагин и попробовал ИИ в деле. Это не просто "ВАУ! КАК КРУТО!", это реально другой уровень разработки, когда ты пишешь не ПО, а ставишь задачу AI-агенту и он ее выполняет, САМ.
Правда, надо честно сказать: весь его потенциал, как и потенциал других плагинов действительно раскрывается только с платными подписками на Cursor или Claude. Лимиты, которые есть в бесплатных вариантах ИИ, не дают нормально работать. Ты больше времени тратишь на ожидание и борьбу с лимитом контекстного окна, чем на саму задачу. И в итоге выгода от работы с ИИ сводится к нулю.
Но если подписка есть - ощущения будут совсем другие.
Дисклеймер
Я не имею отношения к разработке плагина Сергея и не получаю никакой выгоды от его использования или упоминание в этой статье. Я хочу лишь сказать, что это первый инструмент, который показал мне практическую работу AI-агента с 1С. Да, похожих MCP-серверов для EDT уже несколько, я попробовал разные, но именно этот оказался для моих задач, самым удобным.
Не так давно я посмотрел новое видео, где автор, в режиме онлайн с помощью ИИ пишет обработку для ЗУП с нуля. ИИ сам создаёт форму, сам пишет код, сам его отлаживает, конечно не без участия человека, но это на порядок упрощает как разработку так и отладку, когда ИИ можно просто скопировать ошибку и он сам все поправит. Рекомендую посмотреть, хотя бы для понимания того, как уже сейчас можно вести разработку на 1С.
https://m.vkvideo.ru/video-236008654_456239021
https://www.youtube.com/watch?v=R_OMEPEk28E
Вот мой реальный кейс
Пишу запрос в курсоре:
Используй mcp сервер 1c-edt для доступа в 1с. Проблема: иногда, при пробитии чека в кассе - чек печатается, документ "ЧекККМ" сохраняется, данные в ОФД уходят, но статус чека в 1с остается как "отложен". Посмотри, в чём может быть проблема как в основной конфигурации, так и во всех расширениях, особенно в расширении "ИМЯ_РАСШИРЕНИЯ". Обрати внимание на обработку "РабочееМестоКассира", почему так может получаться?
Через пару минут получаю полный разбор: где именно (как оказалось в моём расширении) ошибка и в каком месте логика нарушается и сразу готовый вариант исправления. Где достаточно было нажать на кнопку "Принять изменения" и код будет исправлен сразу в EDT.
При этом, мне не нужно выгружать конфигурацию в файлы, править файлы, затем загружать их обратно в конфигуратор. У вас открыт EDT и код с помощью ИИ правиться там же, не закрывая при этом EDT. Ребята это фантастика!
Для меня это был момент, когда у меня в голове "щёлкнуло". Да это же не просто "чат с ИИ", а настоящий инструмент, который реально понимает контекст конфигурации. Он видел мою конфигурацию, все мои расширения, понимает всю логику, как в основной конфигурации, так и в расширениях. Он не угадывал, не придумывал, не галлюцинировал - он анализировал и выдавал готовый, рабочий код.
Экономия времени? Колоссальная.
Про лень как двигатель прогресса
Переписываясь с автором этого плагина в телеграмме, я написал ему фразу, которая, кажется, про многих из нас:
Я тоже люблю новое, но с возрастом всё труднее выходить из зоны комфорта привычного конфигуратора. Но в качестве дополнительного "пинка" для изучения EDT, может сработать, как ни странно, лень. Когда ты попробовал ИИ в работе, тебе уже лень писать все эти Если... Тогда... Иначе... самому. Ты всё понимаешь, ты можешь это сделать сам, но тебе уже просто лень.
Вот еще мой один реальный кейс:
Вчера вечером я искал косяк в древней конфигурации "Кортес" (адресное хранение). Проблема вылезла после обновления платформы. Загрузил конфигурацию в EDT, прошёлся с ИИ по коду. Проверили всё. Проблема оказалась не в коде, а в ужесточении прав в новой платформе.
Сколько времени потратил бы сам? Не знаю. Но явно больше.
Конечно, нашёл бы. Но попробовал ИИ в деле, искать самому было лень.
Внимательный читатель может мне сейчас возразить: "Как же так? Ты же совсем недавно писал статью "Мой лампово-тёплый конфигуратор 1C", где объяснял, почему работаешь в конфигураторе почти 30 лет и не собираешься уходить. А теперь рассказываешь про EDT, MCP-серверы, AI-агентов… Ты что, переобулся?"
Поясняю свою позицию.
Я не выбираю "или - или". Сейчас я использую оба инструмента.
Конфигуратор - для ежедневной работы, где важна скорость и точность, особенно когда ты точно понимаешь что нужно поправить здесь и сейчас, когда имеешь дело со старыми конфигурациями на обычных формах, которые в EDT просто не открыть для нормальной разработки. Поэтому тут конфигуратор вне конкуренции.
Но есть задачи, для которых сейчас конфигуратор становится неудобен, когда ты понимаешь что можешь решить задачу более эффективно, с меньшими трудозатратами. Работа с большими объёмами кода, массовый рефакторинг, анализ сложных зависимостей, написание нового кода - здесь EDT даёт больше возможностей. А MCP-сервер, который подключает ИИ напрямую к конфигурации, позволяет делать то, что в конфигураторе просто невозможно: ИИ видит метаданные, анализирует код в контексте, предлагает исправления сразу в проекте.
Так что нет, я не переобулся. Просто в моей старой доброй мастерской появился новый верстак с мощным оборудованием.
4. Прогноз. Почему языки программирования станут не нужны
Повторю свою мысль.
Если посмотреть на эволюцию - от машинных кодов до того, как сейчас ведется разработка ПО с помощью ИИ - видна простая закономерность.
Каждый новый уровень абстракции делал старые навыки ненужными. Кто-то должен писать компиляторы и оптимизировать ядро, но массовый программист перестал думать о регистрах микропроцессора.
Сейчас - следующий шаг, любой язык программирования, будь-то 1С, Python, Java или C# - это костыли для человеческого мозга. Нам нужен понятный синтаксис, читаемость, возможность отлаживать глазами.
Языки программирования - это костыли для человеческого мозга.
ИИ вообще не нужен синтаксис. Ему нужна семантика. Логика, связи, ограничения.
Почему языки отомрут
Зачем ИИ писать на Python или 1С, если можно сразу генерировать байт-код? Зачем этот лишний шаг - человекочитаемый синтаксис, который потом всё равно компилировать в машинный или байт-код?
ИИ может мыслить в терминах виртуальной машины. Синтаксических деревьев. Потоков данных. Ему не нужно промежуточное звено в виде языка, придуманного людьми для других людей.
Посмотрите на современные компиляторы: LLVM, MSIL. Это уже промежуточные представления, ближе к машине, чем к человеку. Сейчас мы пишем на высокоуровневом языке, компилятор транслирует в это представление. Если человек будет только ставить задачу ИИ и не будет править код руками, то зачем ИИ писать в какой-то промежуточный язык, если он может сразу подготовить байт-код?
Единая виртуальная машина
Я думаю, лет через 10 мы придём к одному из двух сценариев. Пока неясно, какой именно победит, но оба ведут к исчезновению языков программирования как прослойки.
Первый сценарий: единая глобальная виртуальная машина
Появится глобальная виртуальная машина с единой спецификацией команд. Как у Intel - есть набор инструкций, и любой процессор их понимает. Только здесь это будет виртуальная машина для бизнес-логики, единая для всех платформ.
Не важно, на чём "думал" ИИ. Важно, куда выполнить результат. Он сгенерирует универсальный байт-код, и любая платформа (1С, Java, .NET) сможет его исполнить.
Представьте: вы говорите системе (голосом, текстом - не важно) "сделай мне учёт товаров с партионным учётом и списанием по FIFO". И она не пишет код на 1С, а сразу компилирует это в байт-код для глобальной VM.
Второй сценарий: экосистема вендорских VM
Честно говоря, я больше склоняюсь к этому сценарию. Ведь крупные игроки вряд ли захотят отдавать рынок единому стандарту. У Microsoft будет своя VM, у 1С - своя, у Oracle - своя, а у SAP - своя. Возможно будет Open Source VM или другие варианты. Каждая со своей спецификацией, со своей оптимизацией под конкретные задачи.
И тогда возникает новая роль ИИ - транслятор.
Вы пишете техзадание на естественном языке: "нужен учёт товаров с партионкой и FIFO". ИИ анализирует, в какой среде это будет работать, и генерирует байт-код под конкретную VM. Для 1С - свой, для .NET - свой, для SAP - свой.
По сути, ИИ становится универсальным компилятором с естественного языка на любой целевой байт-код. А разработчик превращается в постановщика задач, который уже не думает о синтаксисе, а только о логике и ограничениях.
Что их объединяет
В обоих сценариях привычные нам языки программирования (1С, Python, Java, C#) исчезают. Потому что они были нужны как промежуточное звено между человеком и машиной. Когда это звено берёт на себя ИИ, необходимость в языках отпадает.
Остаются только:
-
постановка задачи (на естественном языке или в виде схем)
-
байт-код (как единый или как набор под разные VM)
-
ответственность человека за результат
5. Что останется человеку
Мы не исчезнем. Мы превратимся в архитекторов.
ИИ не может взять на себя ответственность. Он не понимает, почему бухгалтер на самом деле просит "разрешить отрицательные остатки" и какие будут последствия для налоговой. Не проведёт переговоры с заказчиком, не объяснит, что его хотелка сломает систему.
Роль программиста сместится от написания кода к постановке задач, проектированию архитектуры, контролю результатов. Мы будем описывать бизнес-логику на естественном языке, а ИИ-агенты - транслировать это в машинный или байт код.
Ручное написание Если ... Тогда ... Иначе станет анахронизмом, как сегодня перфокарты или как написание программы загрузки данных из EXCEL в базу данных на ассемблере.
А вы хотели бы сейчас написать такую программу именно на ассемблере?
Безусловно, в процессе работы вы бы невероятно "прокачали" свой навык программирования. Вы бы узнали многое о регистрах микропроцессора, о работе с прерываниями и распределении памяти под каждую ячейку таблицы. Но какой в этом будет смысл для бизнеса, кроме впустую потраченного времени?
Заказчику не нужны ваши глубокие познания в архитектуре CPU, ему нужны работающие бизнес-процессы, верные остатки и сданная вовремя декларация. Архитектор - это тот, кто понимает, какой инструмент (пусть даже это будет "черный ящик" от ИИ) принесет результат быстрее и надежнее. Роль программиста сместится от написания кода к постановке задач, проектированию архитектуры и контролю результатов.
Что это значит для 1С-специалистов
Если мой прогноз хоть немного похож на правду, через 10-20 лет "программист 1С" как профессия исчезнет. Останется "архитектор бизнес-процессов", который умеет:
-
Понимать, что реально нужно бизнесу
-
Проектировать учётные системы
-
Ставить задачи ИИ-агентам
-
Нести ответственность за результат
Код будет писать машина. Думать - человек.
Можно, конечно, до пенсии сидеть в конфигураторе, править отчёты для мелких клиентов. Но если работаете с серьёзным бизнесом, где цена ошибки - миллионы, меняться придётся в любом случае. Инструмент будет нужен всегда. Но инструмент станет другим.
6. Вместо заключения
Мы прошли путь от регистров до промптов. От книжки про защищённый режим, зачитанной до дыр, до MCP-сервера, который анализирует код быстрее, чем я формулирую запрос.
Остался один шаг. Когда ИИ научится писать не на языках для людей, а сразу в байт-код и тогда это будет точка невозврата. Привычные языки сразу станут не нужны. Как сегодня перфокарты и машинные коды.
Коллеги, а что думаете вы?
А я свой выбор уже сделал - пошел дальше изучать возможности EDT, промпт-инжиниринг и архитектуру агентов.
Другие статьи автора:
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
С 1998 года я писал код в 1С сам, руками, от первой строки до последней. В марте 2026 я рассказывал, как проект на пять месяцев ИИ воспроизвёл за час. Прошло полгода, и теперь я не пишу код совсем, я даже не проверяю его и при этом закрываю 30-40 задач в месяц. Это история о том, что осталось от программиста, когда из его работы ушёл код, почему у одних коллег этот переход получается за месяц, а у других не получается вообще и почему ИИ без опыта за плечами это умножение на ноль.
20.10.2026 5174 GarriSoft 377
О жизни 1C:Бухгалтерия Бесплатно (free)
Как я считаю стоимость своего часа, почему не извиняюсь за цену и что отвечаю на «дорого». Без теории — только то, что работает в разговоре с заказчиком.
11.09.2026 4401 qwerty1414 73
О жизни Россия Бесплатно (free)
Расскажу, как это было у меня. Собеседования я не умею проходить от слова совсем, особенно когда начинают задавать вопросы типа: • Что такое структура? • Что такое соответствие? • Чем соответствие отличается от структуры? • Как обратиться к общему модулю из формы документа? • Как надо обновлять доработанную конфигурацию?
28.07.2026 6095 chuevsf 169
О жизни Россия Бесплатно (free)
Моё личное мнение о перспективах ИИ в среде 1С.
23.06.2026 5314 1c-intelligence 114
30 лет в 1С, 51 год, жёсткие требования к формату работы. За 1.5 месяца нашёл работу, используя DeepSeek как персонального HR-ассистента. Один раз настроил, отправил три своих резюме - дальше просто скидывал вакансии в чат и наговаривал ощущения через микрофон. ИИ анализировал, отсеивал фейки, писал сопроводительные письма, готовил к собеседованиям и разбирал ошибки. Результат: 127 откликов, 2 оффера, выход на работу 1 июня с достойной зарплатой (гибрид, к сожалению, мы с ним не нашли)
20.05.2026 9261 GarriSoft 227
О жизни Россия Бесплатно (free)
В далеком 2007 году я услышал впервые слово «Инфостарт» от своих коллег по работе и нашел этот сайт в Интернете, а 29.06.2007г. успешно зарегистрировался на нем. В течение долгих лет я был «молчуном»: не выкладывал никаких наработок и не писал статей. Просто читал, время от времени, и получал на сайте информацию.
14.05.2026 6072 chuevsf 207
О жизни Россия Бесплатно (free)
Еще совсем недавно у программистов 1С было всё хорошо. Задачи на выполнение сыпались, как из рога изобилия. Счетчик времени зашкаливало от быстроты их выполнения. Чуть ли не каждый месяц был новый рекорд. Новые идеи генерировались бизнесом одна за другой. Но общее состояние экономики в России в 2026 году уже давали о себе знать, и группу компаний также стало лихорадить.
17.04.2026 12019 chuevsf 244
Личные заметки о том, как 1С-разработка столкнулась с вызовом времени. От FoxPro до "гаражной инженерии" - тридцать лет по одним и тем же граблям.
02.04.2026 12947 GarriSoft 280
Не переживайте, раньше точно не исчезнет - бухгалтеры все равно будут ломать свои отчёты ещё лет 50, а кому-то надо их чинить. Так что без нас с вами пока никуда, будем до пенсии объяснять нейросетям, что отрицательные остатки - это плохо.
Токарь с диваном - это вы хорошо загнули! Только вот не задача, нафиг он такой на диване будет не нужен бизнесу.
А если серьёзно сейчас уже идет массовое сокращение, но пока еще профессии электрик и сантехника очень дорогие, можно долго ждать электрика и сантехника особенно в области малоэтажного строительства, все расписано на месяцы в перед, при этом цены совсем не гуманные, даже только за выезд.
Я думаю, что армия сокращенных сейчас пойдет сначала в электрики и сантехники, потом в курьеры, потом еще куда то, на этом пой прогноз обрывается.... я не знаю что будет дальше )))
ЗЫ: реальность ина. Если ты арендовал лисапет, то будешь зарабатывать, если нет - будешь стоять и думать, что тебе заказы сыпаться начнут. Коллега вечерами физкультуры ради бургеркинг разносил - 600-800 руб за вечер в Мск. Сын иногда подрабатывает, ибо студент - антиректорд с одним заказом за целый день.
Ну, гробовщику точно без работы не сидеть - клиенты всегда сами приходят.
А вот программистам, судя по очередям на электриков и сантехников, пора осваивать документ "СП 256.1325800.2016. Свод правил. Электроустановки жилых и общественных зданий. Правила проектирования и монтажа" и разводной ключ.
Рынок труда, он как кладбище: места всегда есть, просто не все пока еще готовы
Всё наше "общение" с компьютером сводится к написанию директив (команд). Отменив языки, мы как директивы в железо будем заряжать?
Короче, Надо сдавать тебя адептам Батлерианского джихада, других путей просто не вижу)
А если серьёзно, то вспоминаю закат СССР. Я работаю на АвтоВАЗе, в одном из его заводов. К нам приехали некие специалисты из Киева (институт Патона), собиравшиеся написать нам программу по САПР. Для чего на экране (уже цветном!) 286-го процессора написали короткий клип, как крутится в трёхмерке обычный шестигранный болт. Для большинства инженеров и программистов это уже тогда не было невероятной тайной, но более высокое руководство завода просто было потрясено и моментально произвело оплату за разработку. Спустя пару лет всем стало ясно, почему на экране крутили болт, ибо именно с ним наш завод и остался. Если кто-то сможет доказать, что ИИ это совсем другое, а не тот же "болт" который просто вырос, раскрасился и стал более эффектно вращаться, как спиралька у гипнотизёра, я с радостью послушаю. Все признаки гигантской финансовой аферы налицо.
А на заявления в стиле "Да сейчас всё ПВО на ИИ!" есть простой ответ. Не надо путать прикладную математику с мыслительными процессами.
Дмитрий, прям ждал твой коммент, все думал. когда...когда... и вот он. )))
По поводу "ИИ может мыслить" - конечно нужно было взять в кавычки, но ты все равно нашел бы с чем не согласится ))) У тебя всегда свое мнение, основанное на своем жизненном опыте.
А под термином "ИИ может мыслить" я хотел сказать, что ИИ все равно что писать или текст программы понятный человеку или сразу байт код для 1с.
И вот как это сказывается на учетных задачах. В учёте (нормальном, бухгалтерском) есть термин "профессиональное суждение". Иными словами можно назвать и "оценочная характеристика", только её обосновывать приходится)
Итак, есть правила учета основных средств. Допустим, надо чтобы стоимость не ниже 100 т.р. была. Но! есть профессиональное суждение главного инженера ТЭЦ, снабжающей город теплом и горячей водой, что прибор учёта гигакалорий, стОящий 60 т.р., является ключевым устройством, фиксирующим производство самого главного ресурса, который создаёт выручку и все налогооблагаемые базы предприятия. И именно по причине значимости в учёте, относительно недорогое устройство переводится в разряд основных средств.
И таких нюансов, не регулируемых ничем и опирающихся исключительно на "профессиональные суждения", в учёте более чем достаточно. Как ИИ даст оценочную характеристику? Не создав алгоритм, как написать код? Неважно, в языке программирования или сразу в нулях-единичках. Интеллект это то, что создаёт алгоритм. А код любая студентка напишет)
Кто-то должен понять великую мысль директора, разобраться в бизнес-процессе и донести это все до ИИ, а потом проверить как все получилось, отчитаться перед директором. Вряд ли директор будет все делать сам.
Но вообще на самом деле и директора скоро заменят на цифрового двойника, я уже писал об этом
Дмитрий, я в ролевые игры предпочитаю играть в другом месте и с противоположным полом и без нейросетей )))
А научная фантастика - это просто фон для размышлений. Хотя если там показывают, как ИИ захватывает мир, я обязательно делаю пометки - вдруг пригодится, когда пойду в сантехники или электрики
Спасибо, не знал, ознакомился, но насколько я понял, он все же больше подходит для получения данных, чем для программирования, там нет инструментов получения и записи кода, создания формы и их заполнения, проверки кода и много других инструментов, которые нужны именно для программирования.
Но для получения данных из 1с, это идеальный mcp, сохранил себе в закладки, спасибо!
В ближайшее время как раз потребуется
Коллега, не согласен, с появлением новых моделей цены должны падать, а не расти.
С другой стороны, 20$, в месяц это не сильно дорого, за возможность ускорить свою продуктивность в несколько раз, даже если работодатель не оплачивает
Коллега, хм, про продуктивность топовой модели - вот мой реальный опыт . Можете подсказать что я упустил ? Я могу рассчитывать что такую элементарную и ненужную мне задачу модель сделает на 5-ку с первого раза? И если сделает сколько $$ она сожрет?
Первое, что бросается в глаза, это hydraai - я ранее его тоже использовал, там да цены небольшие, но слишком маленькое контекстное окно. Второй момент, если вы выбрали одну модель, где гарантия того, что запрос уйдет именно к ней, а не в более дешёвую? Для нас это черный ящик, но надеюсь в hydraai с этим все ок.
Третье, не маловажный момент в самом AI-агенте, как он работает с моделью.
Четверное, важно, какой mcp сервер используется, какие инструменты модель получает в свое распоряжение, их параметры описание, как и когда их лучше всего использовать и т.д.
Далее, вы пишите: "Модель без понятия что в БСП", но здесь дело как раз не в модели, а в mcp сервере, что он позволяет отдавать модели, что что ей нужно.
Попробуйте mcp c хорошей моделью, если не с клодом, хоть с дипзиком, тоже нормально справляется и решает задачи видя в конфигурации все что необходимо.
Думаю совокупность разных факторов, привело к такому результату.
это же прокси...ну камон, вы серьозно? Какого вы провайдера используете?
килокод это усовершенствованный форк roocode, ИМХО тут все хорошо.
Далее, вы пишите: "Модель без понятия что в БСП", но здесь дело как раз не в модели, а в mcp сервере, что он позволяет отдавать модели, что модель может запрашивать и т.д.
тут он использовал tools только про структуру метаданных. и если он не научен БСП то никакой mcp это не расскажет ему? Как вы думаете?
Это странный инструмент...специфический и тем более в edt. deepseek ? Хм, а какой версии посоветуете? И что эта китайская поделка умнее клода в кодинге? Я попробовал qwen3 и glm - там все вообще зациклилось и никакого практически результата не получил..все оч. слабо..совсем
ага, думаю надо добавить еще отвар из летучих мышей и щепотку волшебных грибов )
В случае с какой-то задачей, которую выполучаете вот здесь, сейчас, скармливаете ИИ, получаете результат, я здесь не вижу возможности оценить продуктивность, даи вы не делали замеров. И в эту продуктивность вы должны распределить затраты на получение еавыка пользоваться этим ИИ.
Резюмируя - пустые слова о производительности продуктивности без каких либо замеров.
Поэтому мотивировать людей, что вам жалко что-ли 1600 руб. в месяц для якобы повышения продуктивности упуская все нюансы эксплуатации этого инструмента - звучит, как попытка ввести в заблуждение.
Коллега, вы правы, что продуктивность - это штука сложная, и считать её нужно с цифрами в руках, а не с бубном. Но позвольте вопрос: вы сами пробовали замерить, сколько времени тратите на типовые задачи без ИИ и с ним? Или вы в своей работе не используете ИИ?
Я знаю, поэтому и пишу про ускорение.
Коллега, спасибо, что обратили внимание на этот момент - я действительно не то что упустил, я об этом даже не подумал.
Сначала хотел предложить сохранять финальный промт, который генерирует рабочий байт-код. Но потом подумал: даже с одним и тем же промтом ИИ каждый раз выдает чуть разный результат. Так что сохранять промт - как ловить ветер в поле.
А потом понял: а зачем нам вообще что-то сохранять? Байт-код 1С декомпилируется в читаемый исходник без проблем - без комментариев, но с именами переменных и процедур. То есть ИИ спокойно может работать с байт-кодом так же, как мы сейчас с текстом программы. И никаких промежуточных форматов не нужно.
Так что, возможно, архитектор будущего будет просто смотреть на декомпилированный байт-код и говорить: "Что-то тут не так, перегенерируй". А ИИ "пожмёт плечами" и перегенерирует
Техножрецы заклинают дух машины, посылая ритуальные голосовые промпты, но результат на выходе не соответствует ожидаемому. Поскольку никто уже давно не понимает, как именно получается результат, заклинания повторяются итеративно, в надежде, что дух машины наконец смилостивится...
А самое главное, бухгалтер через 50 лет всё так же будет приходить и говорить: "Дух машины, сделай закрытие месяца!" А техножрец ему в ответ: "Дух не в духе, жди откровения после обеда, а лучше принеси жертву в виде гигабайта оперативки".
И все будут думать, что так и надо, потому что "так исторически сложилось"
Ага - как в бородатом анекдоте про то как китайцы ломали сервер пентагона - где на ярдной попытке за час сервер согласился, что его пароль "MaoDzedong"!
А вообще - в инфраструктуре будущего - если результат, сгенерированный компьютером, не соответствует ожидаемому, и быстро никак не корректируется - значит вы, людишки, явно чего-то не того ожидаете - оно вам и не надо - берите сейчас то, что дают, пока ещё есть, пока ещё можете!
А то вот он житель России всё хочет и хочет.... хочет и хочет... хочет и хочет... например посмотреть котиков на ютубе - а ему система всё говорит - смотри на вк смотри на вк... а человек уже весь лоб расшиб - кучу средств применил и так и сяк уговаривал СТПУ - а никак котиков именно на ютубе не может посмотреть... система твердит и твердит... твердит твердит... твердит и твердит... что там небезопасно и много нежелательного для человека контента - ну не надо туда... смотри на вк... на крайняк на рутуб... да и сдались тебе эти виртуальные котики - лучше сходи в приют - живого возьми - или могу оналйн с доставкой заказать - тебе даже с дивана вставать не придётся - а пальцами шевелить лишь немного - чтобы погладить...
Вот так как раз ИИ системами будущего и будет работать! А человеку просто, на самом деле, уже даже лень пальцами пошевелить будет, чтобы кота погладить... услужливый робот сам погладит по мысленной команде от человека...
На у вообще что-то хотеть большего - это вам не надо - нельзя - опасно - опасно даже думать - расслабьтесь - дышите и существуйте дальше спокойно... без лишних неверных мыслей!
Коллега, вы правы, в своем сообщении (43), а именно, "...смотреть на декомпилированный байт-код и говорить...", я нагалюцинировал, конечно смотреть ни куда не нужно будет. ИИ действительно все равно, с чем работать, с исходником или байт кодом.
Так что, я за "черный ящик" (работающий), что там внутри меня может вообще не волновать, примерно как сейчас совершенно не волнует, как калькулятор производит арифметические действия, теоретически я понимаю, но я об этом просто не думаю.
Метафора про паровоз красивая, но, на мой взгляд, совсем не корректная.
Коллега, вы пробовали AI-ассистента с MCP-сервером, который сам пишет код по ТЗ или ищет ошибку, имея полный доступ к конфигурации 1С?
Попробуйте. У Клода есть бесплатный лимит, на одну небольшую задачу должно хватить. MCP-сервер я в статье указал.
Просто сейчас мы в переходном периоде, новая парадигма ещё не в полной мере осознана.
На следующем этапе должно наступить осознание, что для новой парадигмы нужна новая аппаратная база. То, на чем сейчас работают нейросети, все эти процессоры с пошаговым исполнением - это всё суррогат. Искусственный нейрон должен быть нейроном на уровне железа. И тогда - прощайте, алгоритмы.
Коллега, ну вы прямо нейросетевой апокалипсис расписали!
Тогда вместо суррогата, должно найтись место квантовому компьютеру. А то как-то с развитием ИИ про него все забыли. Потому что если совместить квантовый компьютер с ИИ - тогда точно нас ждёт Скайнет.
Автор правильно начал - про эволюциях языков программирования - фактически приведя поколения ЯП - от условной байт-кода и ассемблера (считается 1-мы поколениям ЯП, хотя я бы разделил их на два поколения), и до виртуальных исполнительных машин, а-ля Java, .NET, 1C, JavaScript (и Питона нет ВМ, кстати - он интерпретируемый, но с очень продвинутым оптимизатором и выходом на машинный байткод) и переходом к управляемой памяти и динамической типизации - хотя, на самом деле, динамическая типизация появилась ещё в семидесятых, а управляемая память... ну не позже 90-х - честно не знаю в каком ЯП, хотя скорее тоже 60-70-ыъх годах - например в функциональны языках программирования а-ля LISP; но и тот же FORTH - тоже родом из 60-70-х прошлого века (разработан в США,Чарльзом Муром - это другой Мур, а не тот, что из Интел; Чарль работал в NRAO) !
Нынешнее мейнстримное поколение ЯП с виртуальной машиной - пока ещё официально относят как-бы в 3+ поколению ЯП. Тут далее нет какой-то устоявшейся классификации поколений, но есть революционные наработки...
Под 4-ым поколением ЯП чаще воспринимают языки, выходящие за рамки текстового кода - например ЯП визуального/графического/схематичного (блочного) программирования, или какие-то Low-Code / No-Code ЯП... можно как-то обобщить на ЯП прикладного уровня (в т.ч. 1С8), которые минимизируют потребность в инструкциях, описывающих "как сделать" - в пользу - как настроить, чтобы оно заработало как требующих! Но... тут нет (или почти нет) текстового кода - что мог бы генерировать ИИ (хотя все схемы всегда можно свести в текст, вот только такие системы программирования не часто это позволяют).
В Low-Code программирование, я думаю, сейчас, стоит двигаться и развитию ЯП в платформах 1С Предприятие / Элемент (но пока тут просто пропасть).
Я же пропагандирую ЯП - 5-го поколения, которые уже изначально создаются с уклоном на применение ИИ технологий, оставаясь в целом текстовыми - что удобно и программисту и искусственному интеллекту!
А, вот, автор решил - что всё - далее развития ЯП уже не будет - только текстовые промты для ИИ!
Вот тут я с автором не согласен! Вернее - рано или поздно и к этому придёт - но точно не за 10-15 лет, да и, я уверен, и 150 - 200 лет тут ещё маловато будет!
А вот появление именно ЯП 5-го поколения может произойти уже к середине этого века - а развиться и стать популярным мейнстримом они могут уже к концу XXI века!
В чём суть ЯП 5-го поколения (кликни, чтобы раскрыть блок) |
|---|
| 1. Такой ЯП остаётся языком программирования - где машине передаются чётко сформулированные команды, придерживающиеся логики наук "информатика", "комбинаторика", порой и других мат. наук, а порой и лингвистических наук - да текстовые промты тут тоже будут нужны!
2. Но происходит качественный переход от описания "как что-то сделать" к описанию "что нужно сделать" - т.е. ЯП 5-го поколения - это декларирование целей и требований - в какой-то степени это текстовый промт, просто подчинённый определённым не сложным правилам и формату подачи. 3. ЯП 5-го поколения - в большей степени декларативный язык, но не брезгующий впитать в себя всё самое лучшее и из функциональных ЯП, а так же ООП, АОП, логических ЯП, и некоторых других направлений. Всё это нужно лишь для одной цели - как можно более выразительно и кратко передать суть требований, описываемых на высоком уровне абстракции, с большим числом неопределённостей! Более того - вся эта декларация напрямую формирует всю структуру контекста решения - чтобы ИИ в ней чётко разбирался. Да и не только ИИ - чтобы и человек тоже мог легко понять что тут задекларировано! 4. Текстовые промты тоже возможны: но, либо как отдельные вставки для решения простых контекстных задач - а-ля чёрный ящик или тут же сгенерированный код решения; либо для поиска уже готовых решений по базе знаний + для их полиморфная адаптация под текущий контекст; либо как быстрое управление средой разработки - например для рефакторинга! Всё-таки сложные задачи через текстовые промты пока не стоит решать - слишком большой риск неточного или не оптимального решения! И есть проблема - с динамикой - о ней ниже! 5. Поэтому процесс декларативного программирования должен быть максимально ориентирован на требовательность, манипулятивность и абстракции. То есть код - это набор требований, набор обобщённых манипуляций над обобщёнными данными, не вникая в тонкости того, что на самом деле за этим все скрывается! От того, ЯП синтаксически и по базовому наполнению объектами - должен быть достаточно прост - очень прост - а вот семантически из этого всего должны быть очень большие возможности что-либо складывать! Как я ЯП FORTH - но это достаточно сложный ЯП, для разработки, если что, с некоторыми пережитками прошлого (всё-таки ему уже за полтинник перевалило) и прошлой архитектуры машин. Но... я уверен (и я сам ориентируюсь), что ЯП 5-го поколения действительно много чему стоит поучиться и FORTH разных диалектов, и его потомком - в основном из семейства как Factor, Joy, Kitten, min и др... 6. Практически любой код на ЯП 5-го поколения не должен привязывать к кой-либо платформе или какому-то стеку библиотек и оборудования (если говорим про прикладной уровень, с системным - там свои заморочки). Но сам код на ЯП 5-го поколения - не интерпретируется и не компилируется (даже в байткод виртуальной машины) - он сам (благодаря, условно, умному компилятору) ориентируется в те текущем контексте решения и его стеке, где всё исполняться должно - и далее генерируется программный код (где-то 3-го поколения, но, в большинстве случаев - управляемый, т.е. не углубляющийся в работу с особенностями взаимодействия с компьютером, где он будет выполняться) - такая прослойка удобна - как для ИИ - чтобы можно было декомпозировать задачу, так и для человека - ведь он тоже может смотреть этот код и вносить правки (лучше в модель деклаирования), а так же подлкючать какие-то отдельные части кода - которые не написаны на ЯП 5-го покления (об этом ниже), и лучше интегрироваться со стеком исполнения и его контекстом (особенно если он не компилируемый - например JavaScript, Python). Затем, если стек среды исполнения позволяет - можно спускаться дальше - на уровень управляемого байткода и затем уже при исполнении, по-потребности, оптимизироваться через JIT компиляцию до машинного кода Но, чем выше сохраняется уровень абстракции - тем больше возможности по интеграции и манёвру оптимизации, и кросплатформенности! 7. Сохранение высокого уровня абстракции кода - это очень важно - для обязательной динамической оптимизации кода для систем на ЯП 5-го поколения. Это очень важная составляющая ЯП. Так как программист больше не задаёт как делать, а только что делать - то как делать за него уже решает ИИ среда! И да, она не всегда может сразу определить оптимальное решение. Но она может сразу (или потом) подготовить несколько различных рабочих решений. Поэтому далее, уже по факту реального исполнения кода (в т.ч. спустя длительное время - ведь может меняться и среда исполнения и обрабатываемые данные, и способы обращения к ним и к алгоритму) - что потребует пересмотра решения и его переоптимизации - вот это и есть динамическое репрограммирование - по готовым декларациям - вида "что надо сделать" - код заново генерируется, учётом собранной статистики выполнения прошлого кода (или сразу могло быть создано несколько вариантов решений, применяемых попеременно - со сбором статистики) - и выбирается другой вариант для продолжения эксплуатации - уже без участия программиста (но он может быть уведомлён)! Более того - может быть автоматически создан гибрид из нескольких вариантов кода - с ветвлением под разные состояния среды и входные данные. 8. Само собой, чтобы это всё было надёжно - то помимо исполнительного кода, по декларации должны генерировать и тесты, чтобы ИИ сам мог эффективно тестировать решение на корректность, особенно при динамическом репрограммировании без программиста (а в идеале - для ИИ может быть выделен целый тестовый стенд - где он сможет проводить предварительные тесты, и даже ставить эксперименты, прежде чем переносить всё в продуктивную среду, где так же продолжать тесты). Ну и сами декларации должны быть очень точны и понятны для ИИ (и для человека) - максимально избегающие двусмысленности! Так же тут, ИИ, может сразу генерировать и автодокументацию к решению - всё по той же декларации! 9. Так же ИИ активно сам следит за ошибками - как рантайм (где он тоже вправе их либо быстро фиксить, либо откатывать на предыдущую версию алгоритма), так и статически - активно проводя анализ декларативного кода на предмет ошибок! Ну и рефакторинг тут тоже должен быть очень продвинутый! 10. Хотя... вместо рефакторинга чаще нужно просто повышать уровень абстракции объектов кода - когда их детали структуры и реализации далеко не определены в точке применения. Но к ним можно выдвигать декларативные требования - например на поддержку какого-либо контракта API, или требование наличие определённых полей. Но и тут всё тоже может быть очень не конкретно - можно требовать некоторую функциональность, без явного требования чётких имён и типов. А ИИ система сама подгонит что есть - к тому что нужно, или проведёт анализ и скажет что вот есть только это, а вот этого не могу найти - и тут уже нужно либо смирится, либо исправить ошибки проектирования, либо сделать умные ветвления с заделом на будущее - если вдруг появится то, чего нет сейчас. Вот, вкратце, как-то так, я представляю будущее развитие программирование - на сотню лет вперёд! И ещё. Декларативный ЯП 5-го поколения - это хорошо. Но... порой всё-таки нужно спускаться на уровни ниже - на 3-е поколение - например, для написания каких-либо библиотек, требующих веского уровня оптимизации, при минимуме абстракций (не обязательно) и веского уровня единения с математикой или оборудованием, или особой интеграции с другими системами. Поэтому ЯП 5-го поколения должен легко поддерживать переход на более низкий уровень уже классического императивного программирования! Всё-таки ЯП 5-го поколения - это больше прикладной уровень на высоких абстракциях. Но и системное программирование тоже можно довести и до частичного применения ЯП 5-го поколения. |
Про единую экосистему с единой виртуальной машиной я пока не верю - не в этом веке.
А вот в единый подход у разных ЯП - на которых можно будет единообразно писать код (и создавать библиотеки) под разные стеки исполнения - я верю!
Коллега, спасибо за развёрнутый ответ и экскурс в историю ЯП, чувствуется ваш фундаментальный подход!
Но позволю заметить, что пока ИИ учится отличать FIFO от LIFO в 1С, а программисты, ставить EDT в третий раз, я, наверное, всё же продолжу писать промпты и иногда еще и код. А через 100 лет, если ИИ будет сам себе генерировать тесты и документацию, я готов уступить место. Главное, чтобы он тогда не спросил: "А зачем вам, людям, вообще эти ваши декларации?" )))
P.S. Конференцию Инфостарт по ИИ в 1С поддерживаю обеими руками!
И я же указал - для советских спецов. Так-то в разных языках было.
Аналогично, когда фароновская книжка вышла, для всех стал открытием Паскаль, хотя TP5, или первый объектный 5.5, уже вовсю были...
Python/JavaScript/1С - уже не просто не думаешь про память, ты не думаешь про типы. Всё динамическое, гибкое, и все прощающее. Можно быстро набросать нужное решение, не заботясь о строгости.
Нижние нифига не следующая ступенька, а тупиковая ветвь развития. Время показало, что статическая типизация это гораздо лучше и надежнее, чем динамическая. Во времена умных IDE весь профит от динамической типизации сошел на нет и даже ушел в минус. На примере того же мегапопулярного JavaScript, сразу два гиганта выкатили убивцу этого ЯП со статической типизацией: гугл выпустил Dart, а майкрософт выпустил TypeScript. Даже фирма 1с выкатила Элемент, в котором используется статическая типизация
Коллега, согласен, что код сегодня - это часто единственная правда. Но в будущем, все буде проще, если байт-код будет генерироваться ИИ, смотреть в него будет примерно так же полезно, как читать дамп памяти. Документацией станут не исходники, а описание бизнес-процессов. В крайнем случае, даже если кто-то уволился и описания нет - спросишь у нейросети: "а почему тут так?" и получишь ответ. ИИ посмотрит на байт-код и восстановит текущий бизнес-процесс
1. Не все ИИ полезны, особенно те которые пишут код наугад, без mcp сервера, не видя конфигурации.
2. Вас не смущает другие черные коробочки, в виде разных программ к исходному коду которых у вас нет доступа?
3. А как сейчас сдаются отчеты? Бухгалтер ни чего не проверяет, сразу кнопку отправить нажимает?
Бухгалтер сейчас проверяет, и если где-то сальдо с бульдо не сошлось пинает программиста, тот выясняет почему не сошлось и правит исходный код, чтобы работало правильно. Причем бухгалтер не может сказать, почему работает неправильно, он только проблему обозначает. Для ИИ такая постановка задачи не проканает
Проканает, я описал в это статье своих два кейса, когда я не знал, из за чего ошибка возникали, это "про ЧекККМ" и "про 1с:Кортес", когда он частично ломался после обновления платформы, в обоих случаях ИИ помог найти причину, достаточно быстро, я сам бы тоже нашел, но тут вопрос времени.
я не писал ему ТЗ, промт для первого кейса приведен в статье "один в один", его одного было достаточно, чтобы курсор использую mcp сервер нашел причину
А хотелки кто будет формулировать? И сверять полученное с ожидаемым?
У меня несколько было мелких поектов, связанных с бонусными программами розницы, написано фронт и бек с api без единой правки кода руками, только промт, ввиде замечаний, как обычному человеку-программисту, можно даже поругать его, если накосячит.
Самый прикол я потом дал ему css файл и сказал поправь стиль, чтобы вписался в существующий сайт, 5 сек и все готово, раздел стал как "родной" на сайте.
Буквально сейчас развивается то, чего остро не хватало - MCP-переходники. Ещё б типовой конфигуратор мог с ними сотрудничать, была б красота... Сейчас уже действительно становится видно участки, где от БЯМ будет отдача.
Коллега, чувствуется вопрос с подковыркой, чтобы завести диалог, ну ок ))
Тогда может, стоит увольнять тех, кто не хочет развиваться в профессиональном плане и не использует современные инструменты, позволяющие увеличить производительность в несколько раз?
Я не восхищаюсь ИИ, я проверяю, тестирую, отбираю инструменты, которые реально экономят мне время. Если вам удобнее писать всё руками и считать это единственно верным путём — ради бога. У каждого свой подход. Но называть 'бредогенератором' то, с чем вы не работали — это странно для взрослого человека в профессиональном сообществе"
Как когда-то ООП не убило процедурное программирование, а просто добавило новый способ мышления, так и LLM не убьют языки программирования. Даже сейчас можно найти программиста на ассемблере. В нашем 1С-сообществе был дядька (царство ему небесное, уже покойник), который написал декомпилятор запроленных конфигураций на ассемблере.
Самое вероятное будущее — гибридный язык: 70% промптов на естественном языке и 30% точных конструкций для случаев, с которыми LLM не справляется. То есть LLM просто станут лучшим автокомплитом и инструментом рефакторинга, а не заменой программисту.
Так что ассемблер спит спокойно. Как и C. Как и Java. LLM умрут раньше, чем они.
Коллега, не стоить думать что ваше предположение - это истина в последней инстанции и только вы все правильно понимаете, может быть стоило начать по другому вместо "Вы неправильно понимаете эволюцию языков", написать "Я считаю по другому".
По поводу автора декомпилятора для 1с, вы вероятнее всего имели ввиду Валерия Агеева ака AWA? Но его обработка была написана на 1с, а не на ассемблере.
В целом я не согласен с вашим комментарием, у меня свое мнение.
Коллега, наверное я вам открою секрет, а не вы мне.
Видимо речь идет о библиотеке Cv8cf.dll, которая в составе обработке, в виде макета, верно?
Во первых, она написан не на ассемблере, как вы утверждаете в (106), странно в наше время писать на нем, если можно гораздо проще написать на языке более высокого уровня, верно?
Так вот, данная библиотека, написанная на C++, с использованием фреймворков ATL (Active Template Library) и VCL (Visual Component Library), а также технологии COM (Component Object Model). Это видно если вы откроете dll в блокноте.
Второе, что делает эта библиотека?
Вот анализ данной библиотеки с помощью ИИ
Исходя из анализа экспортируемых функций, строковых ресурсов и названий классов, библиотека реализует функционал для работы с архивами и сжатыми файлами.
Вот основные возможности, которые можно выделить:
Работа с архивами (ZIP, CAB, TAR, GZIP):
Классы с именами TAbZipArchive, TAbTarException, TAbGzipException прямо указывают на поддержку различных форматов архивов.
Обнаружены методы для создания, добавления, извлечения, удаления и обновления файлов в архивах (AddFiles, ExtractFiles, DeleteFiles, FreshenFiles).
Есть поддержка многотомных (spanned) архивов (классы TAbSpanStream, TAbSpanMode).
Реализация алгоритмов сжатия (Deflate/Inflate):
Наличие классов TAbDeflateHelper, TAbDfDecodeHuffmanTree и алгоритмов "Deflate" и "Inflate" говорит о том, что компонента может сжимать и распаковывать данные, используя стандартные алгоритмы (в частности, алгоритм Deflate, который используется в ZIP и GZIP).
Шифрование/Дешифрование:
Классы TAbZipDecryptEngine и TAbZipEncryptEngine, а также строки типа "Enter Password" и "Invalid password" указывают на поддержку парольной защиты ZIP-архивов (вероятно, традиционный ZipCrypto или AES).
Дополнительные утилиты для работы с файлами и памятью:
Работа с путями: функции AbAddBackSlash, AbStripDrive, AbParsePath и т.д. для манипуляции с именами файлов и папок.
Временные файлы и память: классы TAbTempFileStream и TAbVirtualMemoryStream для эффективной работы с данными, которые могут не помещаться в оперативную память.
Взаимодействие с 1С:
Библиотека экспортирует стандартные для внешних компонент 1С функции:
GetInfo — возвращает информацию о компоненте.
RegisterExtensionAs — регистрирует расширение.
GetNProps, FindProp, GetPropVal, SetPropVal — для работы со свойствами компоненты.
GetNMethods, CallAsProc, CallAsFunc — для вызова методов.
Основной вывод:
Эта библиотека (Cv8cf.dll) является внешней компонентой для 1С:Предприятия, которая предназначена для архивации и работы со сжатыми данными непосредственно из кода 1С. Она позволяет создавать, читать, распаковывать и модифицировать ZIP-архивы, а также, вероятно, архивы других форматов (CAB, TAR, GZIP). Название "v8cf" (где "cf" может означать "compression framework") подтверждает это назначение.
Скорее всего, это компонента от стороннего разработчика (или самописная), которая добавляет в 1С возможности, которых нет в стандартном функционале платформы (например, для работы с ZIP-архивами с паролем или с многотомными архивами).
Третье, получается данная обработка позволяет распаковывать и запаковывать файлы cf, epf в виде обычных файлов и папок и запаковывать их обратно, тут действительно гораздо проще использовать готовые библиотеки для работы с контейнером, который представляет из себя файлы 1с, чем писать этот алгоритм на 1с.
Четвертое, после того, как файлы распакованы из контейнера и лежат на диске, нет ни какой трудности анализировать их с помощью кода 1с, т.е. превращать байт код в модуль 1с.
Кроме того, есть в интернете ОТКРЫТЫЕ обработки декомпиляции байт кода, написанные на 1с, которым требуется только готовый файл с байт кодом для их работы. Можете найти их в интернете и изучить их исходный код написанный на 1с.
Коллега, я ни какую суть не упускаю, думаю вам нужно изучить что из себя представляет байт-код 1с, для виртуальной стековой машины 1с.
Байт-код - не зашифрован. Он просто лежит в открытом виде, не важно пароль установлен или модуль отсутствует.
Если вы устанавливаете пароль на модуль, то ваш модуль шифруется с вашим паролем, но байт-код остается как есть. Пароль при этом не хранится, при открытии запароленного модуля, 1с пытается применить введенный пароль и расшифровать, если не получается, пишет, что пароль не верный.
Если вы вообще удаляете модуль, то байт-код все равно остается, так же в не зашифрованном виде.
Ни чего не нужно перехватывать, ни какие вызовы. Какие ассемблерные блоки? О чем вы говорите?
Коллега, все гораздо проще!
У вас есть в открытом виде лежит файлик с байт-кодом, и из него восстанавливается исходный код модуля.
Почитайте как это работает, хотя бы здесь:
Да, вы правы. Я действительно путал машинный код и байт-код. Для меня они были одним и тем же — ну инструкции и инструкции.
Но разница есть.
Машинный код исполняется процессором. Чтобы с ним работать, нужен ассемблер, регистры, память процессов — всё серьёзно.
Байт-код 1С исполняется виртуальной машиной 1С. Он лежит в файле в открытом виде. Его не нужно взламывать — достаточно знать формат и уметь парсить.
Поэтому мои слова про ассемблер были неверны. Декомпилятор спокойно пишется на чистой 1С. Спасибо, что поправили.
Дополню свой ответ из (111)
В этой статье по ссылки из предыдущего моего сообщения, так же описан принцип, почему не возможно иногда декомпилировать байт-код,
Делают подмену байт-кода, при этом, виртуальная стековая машина 1с, спокойно выполняет байт-код, но для этого операнда просто него нет, аналога в языке 1с, вот и весь секрет, того что модуль невозможно декомпилировать.
Но и это решается, сначала обрабатывают байт-код, находя вот такие конструкции, а уже потом декомпилируют байт-код в исходник.
Рейтинг: 801
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 2634060
Создание 10.03.26 11:40
Обновление 10.03.26 11:40
Просмотры 4282
Загрузки 0
Рейтинг
15
Комментарии 112
Код открыт Да
Рубрики О жизни
Кому Разработчик
Тип файла Нет файла
Платформа Не имеет значения
Конфигурация Универсальные
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
