>> руками ли ты переписываешь или автоматически
> Тут я не копенгаген по части практической, но теоретически - машинная трансляция
> по заданным правилам как раз позволяет избежать необходимости ручной выверки кода.

Я думаю, что такой компилятор можно написать, но он нагенерит тебе такой код, что лучше в него не заглядывать даже. Фишка ведь в том, чтобы получить код, который затем можно поддерживать.

>> Автоматическая конвертация избавляет тебя от собственно переписывания кода.
> Хороший вопрос - насколько...

Да, хороший вопрос. Судя по заявлениям этой статьи, нейросетка избавляет лучше, чем rule-based конвертация.

>> Тебе точно так же надо будет писать тесты
> Не понял, а что мешает сконвертировать тесты?

Если они есть, то их можно скомпилировать. Наверное. Возможно привнесение багов в процессе компиляции, вопрос в том, насколько, вероятно, что баг внесённый в функцию не задетектится тестом, потому что в тесте тоже появился баг.

Я не могу сказать, на самом деле, потому что я не переписывал код с поддержкой транскомпилей. Мне приходилось работать с кодом, переписанным таким образом при помощи p2c, но тот код уже был переписан до меня и уже был в работоспособном состоянии, когда мои ручки до него дотянулись. Кстати исходно я исследовал тот код, допиливая его до лучшего состояния. Например, заменяя вызовы writeln на вызовы printf. И приводя к верхнему регистру все константы объявленные через define (в исходном паскалевском коде они, видимо, употреблялись в разных регистрах, и то ли p2c, то ли тот кто правил код до компилируемого состояния, решил эту проблему посредством множественных define'ов для каждой константы -- под каждое написание константы отдельный define.

>> При автоматической трансляции, я полагаю, будет больше сфейлившихся тестов, и поэтому исправление багов трансляции займёт больше времени.
> У тебя какое-то болезненное чувство к наборам тестов.  Это полезно для
> выявления каких-то
> тривиальных вещей, для уверенности что каждый кусок кода хоть где-то - отработал.
> Но - не более.

Вопрос не в тривиальности тех вещей, которые ловятся, а в количестве тех вещей, которые не ловятся (точнее мы не можем знать это количество, и скорее надо говорить о матожидании этого количества или о вероятности напороться на такие вещи). А это уже к тому, каким образом пишутся тесты.

Кстати, когда ты переписываешь код, то можно писать тесты, которые сравнивают работу старого кода с новым. Причём не только результат работы, но и внутренние состояния программ можно сравнивать на разных этапах их выполнения. Я делал так. Понятно, что сравнивать адресные пространства побайтово не получится, даже значения переменной x из исходного кода со значением переменной x из целевого кода не всегда получится сравнить, потому что переменная может прекратить существовать или изменить смысл. Но какие-то переменные остаются, и их можно отслеживать.

Это очень напоминает фишинг. Чем больше тестов, чем подлее тесты, тем больше шансов отловить возникший баг. Плюс помогает опыт: если писать тесты, а потом разглядывать багрепорты о багах, которые проскочили сквозь сеть тестов, и при этом задаваться вопросом о том, как надо было писать тесты, чтобы эти баги не проскочили, то со временем учишься писать тесты так, чтобы через них проскакивали бы только редкие баги. Отчасти опыт можно заменить чтением книжек о тестировании и, кстати, философией. Тесты -- это тоже своего рода способ познания реальности. Нужно вогнать себя в нужный майндсет, прежде чем писать тесты -- надо целенаправленно пытаться порушить код тестом. Надо научиться чувствовать в себе неуверенность, которая возникает при идее засунуть в функцию какие-нибудь подлые данные -- если неуверенность есть, значит НАДО СРОЧНО ВЗЯТЬ И ЗАСУНУТЬ. Тесты часто пишут проверяя что код делает то, что задумано, но надо писать тесты так, чтобы заставить его сделать то, что не задумано.

Очень полезно, когда тест пишет не тот человек, который писал код, и который будет править код, чтобы тот справился с тестом, показавшим, что код кривой. Когда пишешь тесты под свой код, во-первых, сложно придумать кейс на котором код сфейлится: если ты об этом кейсе можешь подумать, то скорее всего ты уже о нём подумал, когда писал код, и учёл этот кейс в коде, и тестом ты лишь отметишь факт того, что ты об этом подумал, когда писал код. Во-вторых есть тенденция делать слишком много допущений о корректности кода -- отчасти потому, что ты точно знаешь как код написан и что он делает (точнее думаешь, что точно знаешь), отчасти потому, что где-то в глубине психики ты знаешь, что если ты напишешь тест, который порушит код, то тебе придётся тратить дополнительное время на отладку кода и исправление. Понятно, что это глупость, но так работает психика: каждый раз когда ты тестом доказал кривость кода, психика воспринимает это как наказание, начинает вырабатываться условный рефлекс, что хороший тест -- это плохо, и этот рефлекс начинает модифицировать твоё поведение в процессе написания тестов так, что ты будешь писать тесты, которые покажут, что код хороший, годный, безбажный. Надо уметь контролировать эти психические процессы, чтобы они не мешали. Или (что лучше) оставлять написание тестов кому-нибудь ещё, тому кто будет получать бонус к премии за каждый тест, который порушит твой код, для кого тест, порушивший твой код, будет не наказанием, а подкреплением и, соответственно, у него будет вырабатываться рефлекс, что хороший тест -- это хорошо. И этот рефлекс будет автоматически подталкивать его к написанию хороших, подлых тестов, так что тот кто писал код будет чертыхаться и бормотать себе под нос, что тестер извращенец и ему давно пора в психушку.

>> Вот эти человекочасы вычитаются,
>> из процесса транскомпилем, и добавляются дополнительные человекочасы на большее количество
>> сфейлившихся тестов.
> Я опасаюсь что из этого, для начала, ты не вычел время на
> чтение и понимание трансконпилировавшегося (или нет) текста...  Читать машинное творчество
> непросто, да.

Одна из фишек этих транскомпилей -- генерить читабельный код. По-крайней мере не менее читабельный чем оригинальный. Нет никакого смысла транскомпилировать, если результат нечитаемый. Точнее есть, но для совсем других задач -- это когда лень писать компилятор в машинный код, и поэтому компилируем в C, чтобы потом C скомпилировать компилятором. Но в новости речь о транскомпиляторах нацеленных на бесповоротный перевод проекта с одного языка на другой. Нет никакого смысла переводить проект с языка на язык с потерей читабельности кода.

>> Переписывание -- это тупая рутина
> Не совсем.  Разные языки - разные стили программирования.  Т.е. если
> даже в рамках
> одного языка - это задача, то различие языков просто вынуждает к рефакторингу.

Да, но через неделю-две ты понимаешь, что этот рефакторинг -- рутина. Поначалу вроде как приходится думать, но потом мышление становится ненужным, потому что все проблемы решаются из памяти по аналогии с уже решёнными проблемами. Ещё через пару недель хочется выть от того, что делаешь руками то, что можно было бы сделать алгоритмически. Я в компьютерные игры довольно давно уже не могу играть, потому что мне хочется выть от того, что большая часть активности может быть автоматизирована алгоритмически. Но тут будет ещё хуже, в этот момент начинаешь писать бажный код, потому что нет двух абсолютно одинаковых проблем, и перенося решение с одной проблемы на другую надо остановится и подумать о том, насколько такой перенос будет валидным, и поначалу останавливаешься и думаешь, но и эти мысли о валидности переноса решения становятся рутиной, и вместо того чтобы думать их, начинаешь извлекать их из памяти в обдуманном виде, и... короче рекурсии не получается, мозги начинают срезать углы и начинают лепить баги.

>> Ну, эмм... я не знаю, если честно, но я бы не полагался
>> на отсутствие логических ошибок.
> Про это я писал.  Как тебе трансляция одной логической ошибки -
> в две?  Или в 10?

Я к этому отношусь оптимистично: если используемые методы детекта логических ошибок хоть чего стоят, то мультипликация логических ошибок повышает шансы заметить их наличие, а значит и шансы на исправление. При этом, если у тебя есть исходный код и скомпилированный код и они работают по разному, то тебе придётся исследовать и тот, и этот, чтобы разобраться, и при некотором везении  ты начнёшь видеть ошибки не только привнесённые, но и те, что уже были.

> Вот поэтому мне и кажется это бесперспективным.  В отличие от задач,
> где легко
> можно проверить результат, но сложно его получить обычными алгоритмами.

А фейсбуку не кажется. И мне не кажется.

>> Но как бы там не было, нельзя полагался на результат переписывания, каким
>> бы образом он бы не был получен -- ручным переписыванием, rule-based
>> транскомпиль, нейросетка... какая разница?
> Разница есть.  rule-based - дает определенные гарантии о поведении результата.

Я не верю в эти гарантии. Если rule-based -- это механический перевод, который, например, при трансляции C++ -> Python, начнёт запиливать в Python'е модель памяти C++, указатели C++, массивы C++, и так далее, если при этом количество правил не такое уж и большое, и правила простые, если внешние API на, которые полагаются исходный и целевой код -- одни и те же, то можно довериться. Но если мы переводим код с использования STL и boost на стандартные Python'овские библиотеки или обратно, то верить такому переводу нельзя. Такой перевод потребует безумное количество правил, среди этих правил будут достаточно сложные, проверить каждое правило задачка ещё та, доказать что эти правила ни при каких условиях не помешают друг-другу практически невозможно.