> Непонятны не слова, а цифры. Как ты "around $750 million and
> 5 years of work to convert its platform from COBOL to
> Java" конвертируешь в "chaper solution", если все-равно
> необходимо "manually adjusting" конвертировать труд этой бредогенерилки?
>> Речь идёт о том, что транскомпиль используется для перевода, и результат затем
>> обрабатывается вручную.
> Если раньше был необходим труд специалистов и теперь необходим труд специалистов -
> то в
> чем разница?А, тебе не приходилось переписывать код? Процесс может быть организован по-разному (можно переписывать сразу всё целиком, можно переписывать функцию за функцией, после каждой добиваясь работоспособности, можно переписывать большими блоками -- типа подсистему за подсистемой), но этому процессу, по-любому, неплохо было бы включать в себя фазу покрытия исходного кода тестами, которые затем можно применить к переписанному коду, с тем чтобы сравнить результаты. В любом случае -- руками ли ты переписываешь или автоматически -- тебе придётся заниматься выверкой кода, потому как привнесение новых ошибок неизбежно.
Автоматическая конвертация избавляет тебя от собственно переписывания кода. Тебе точно так же надо будет писать тесты, точно так же надо будет выяснять причины, почему тесты фейлятся. Но переписывать не надо будет. При автоматической трансляции, я полагаю, будет больше сфейлившихся тестов, и поэтому исправление багов трансляции займёт больше времени. Но переписывание кода довольно долгий процесс, это существенно быстрее, чем писать с нуля, но ты сам подумай: сколько человекочасов надо чтобы переписать 100k строк? Вот эти человекочасы вычитаются, из процесса транскомпилем, и добавляются дополнительные человекочасы на большее количество сфейлившихся тестов.
И это очень полезно: гораздо полезнее тратить время на поиск и исправление багов, нежели на переписывание. Переписывание -- это тупая рутина, которая неизбежно приводит к тому, что внимание рассеивается, концентрация теряется, и вот ты уже добавляешь один баг за другим, и при этом твои баги гораздо более креативны нежели любые баги, которые может привнести алгоритм: чем больше интеллекта, тем заморочнее его ошибки.
>> Наличие _коммерческих_ rule-based систем
>> прямо намекает на то, что под них есть рынок и этот
>> сценарий перевода с поддержкой транскомпиля -- это не просто фантазии автора,
>> это вполне себе рынок, где люди работают и даже ради этого запиливают софт.
> Этот софт работает на других принципах. В частности, результат гарантированно
> синтаксически корректен, он также не добавляет новых логических ошибок.
Ну, эмм... я не знаю, если честно, но я бы не полагался на отсутствие логических ошибок. Синтаксические же ошибки... Ну во-первых здесь в новости написано, что они по большей части корректируются дополнительными ограничениями в декодировщике. Во-вторых, синтаксические ошибки -- это туфта. Их исправление это конечно муторная отупляющая рутина, но они правятся элементарно. Вот когда новый код ведёт себя не так, как вёл себя старый, вот тут можно серьёзно залипнуть на исследовании старого кода, который хрен пойми что и как делает, и/или выяснении причи, почему новый код ведёт себя иначе.
Но как бы там не было, нельзя полагался на результат переписывания, каким бы образом он бы не был получен -- ручным переписыванием, rule-based транскомпиль, нейросетка... какая разница? В любом случае будут привнесены новые баги, а старые неисправленные усугубятся. А раз доверия коду нет, значит валидация, валидация и ещё раз валидация. Причём не глазами -- глазами человек очень плохо ищет ошибки. Причём с нелокальными ошибками всё гораздо хуже (то есть с ошибками, которые нельзя увидеть анализируя код в окрестности какой-то строки, которые можно заметить, только если посмотреть в три разных окрестности трёх разных строк и прокрутить какой-нибудь специфический сценарий работы этого кода). Unit-тесты очень заходят, интеграционные тесты тоже весьма и весьма полезны.
