Что будет более продуктивным? Преобразование VAX PASCAL в GNU PASCAL или перенос его на perl или другой язык
У меня есть эта устаревшая кодовая база (Compaq PERL), около 1500 строк кода, которую мне нужно перенести на Windows. Я хотел использовать GNU PASCAL (который я установил и работаю). Я уже получил наш ассемблер (HP 64000 8051) от VAX и на Windows (KEIL 8051).
Директор по разработке программного обеспечения хотел бы получить все продукты от VAX. Вот в чем проблема, я попытался скомпилировать PASCAL из VAX на CYGWIN, используя gpc. Кажется, есть много вещей, которые необходимо сделать, чтобы получить (IO и алгоритмический) эквивалентность от одного PASCAL к другому.
Я достаточно хорошо знаю PERL,FORTRAN,C и C++ (и JAVA, но я бы не хотел). Мой вопрос сводится к 1500 строкам кода. Было бы более продуктивно перенести код PASCAL на другой PASCAL или было бы более продуктивно перенести его на другой язык? VAX PASCAL был моим первым языком в колледже, но я активно не изучал его в течение 8 лет. Я работаю с PERL,C,C++ и FORTRAN все часто и профессионально.
Я бы сказал, насколько это возможно, если бы я собирался перейти на другой язык, PERL был бы именно таким.
Код выполняет заливки и контрольные суммы для файлов изображений INTEL hex и TEX HEX. Я знаю о программе Srec 1.4, которая будет работать, но это не вариант, потому что я должен получить свой код, пригодный для DO-178B (и моя компания опасается использовать открытый исходный код)(у них нет проблем с открытым исходные инструменты; просто код).
5 ответов
Учитывая, что это всего 1500 строк кода, и хотя у Pascal было много достоинств, ввод-вывод не был одним из них, я перенес бы все это на C, разбив его на модули и написав несколько модульных тестов. Портирование на новый Паскаль - это большой "неизвестный фактор" в том, насколько совместимы разные диалекты. Если вы перенесете его на C, то к концу первого дня вы узнаете, сколько времени займет работа, и как только вы это сделаете, она будет тщательно завершена, потому что C переживет нас всех. И я согласен с Джоэлем Нили; всегда будет легко найти другого программиста на С для его поддержки.
Поскольку программа настолько мала, в основном это операции ввода-вывода и целочисленные операции, я не вижу здесь роли для C++. Не стоит дополнительной сложности.
Я бы попробовал перенести его на Free Pascal, но с ограничением по времени. Если это слишком сложно, вернитесь к более недавно используемому (вами) языку.
Есть ли способ проверить, ведет ли себя новая (перенесенная или переведенная) версия так же, как старая?
Я думаю, что перенос 1500 строк кода на любой язык / платформу не должен быть слишком сложным, учитывая тот факт, что все, что вам нужно сделать, это "выполнить заливку" и вычислить контрольные суммы. Лично я бы предпочел C# - это оказывает успокаивающее влияние на мой разум:), но учитывая ваше мастерство в C / C++, я бы посоветовал вам перейти на C++ по той простой причине, что C++ - лучший в мире язык ассемблера и будет соответствовать вашим требованиям. в совершенстве. Я думаю, что Паскаль - это то, что устарело, и новые проекты должны избегать этого. Пожалуйста, не стесняйтесь поправлять меня, если я ошибаюсь.
Программирование на C - это непростая задача, и оставить место для дальнейших улучшений вашей программы C++, кажется, лучший вариант. Также не забывайте, что в отличие от C, C++ имеет несколько очень способных библиотек для его резервного копирования (STL, Boost и т. Д.).
Сначала я бы подумал о долгосрочной ремонтопригодности (в том числе кем-то, кроме вас). Если, например, вы единственный, кто знает PASCAL и не хотите быть единственным владельцем поддержки и поддержки этой программы, то PASCAL может оказаться не таким хорошим выбором, как язык с более широкой базой разработчиков. в вашем магазине.
Если это не проблема решения (например, несколько разработчиков, все в равной степени знакомы с одним и тем же диапазоном языков), то я бы оценил время для порта gnu PASCAL ко времени, например, для порта Perl, и выбрал бы целевой язык, который занимал бы меньше время использовать.
Если это также не проблема решения (то есть эквивалентный уровень усилий), то я бы посмотрел на экономию времени выполнения (более высокая скорость, меньший объем памяти).
Я всегда стараюсь писать программы как можно больше на языке, который использует компания.
Нет смысла прибегать к языку сценариев (потому что это фрагмент проще), если в компании сидят шесть программистов, работающих на C++, что повышает требования к языку при следующем найме.
Лично я негодую на Perl, потому что синтаксис немного криптографический. Более того, это не такой "корпоративный" язык, особенно здесь, и за пределами системного уголка Unix трудно найти людей, которые действительно в нем разбираются (*)
Обратите внимание, что это просто рецензия с моей текущей точки зрения, которая в основном написана программистом в небольшом магазине с крупными коммерческими клиентами, которые навязывают нам свои методы. YMMV.
(*) webdevels делают в основном ASP.NET здесь.