Что было бы более продуктивным? Преобразование VAX PASCAL в GNU PASCAL или перенос его на perl или на какой-либо другой язык

Question

У меня есть эта устаревшая кодовая база (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 будет, если я собираюсь перейти на другой язык.

Что делает код, выполняет заливки и контрольные суммы для файлов изображений INTEX hex и TEX HEX. Я знаю о программе Srec 1.4, которая будет работать, но это не вариант, потому что я должен получить свой код, подходящий для DO-178B (И моя компания не любит использовать открытый исходный код) (у них нет проблем с open исходные инструменты, просто код).

Answer 1

Учитывая, что это всего лишь 1500 строк кода, и что, хотя у Паскаля было много достоинств, I/O не был одним из них, я переносил бы все это на C, разбивая его на модули и записывая некоторые модульные тесты вдоль путь. Портирование на новый Паскаль есть большой «неизвестный фактор» в том, насколько совместимы разные диалекты. Если вы портируете его на C, вы узнаете к концу первого дня, сколько времени займет работа, и как только вы это сделаете, вы полностью ее пригвоздите, потому что C переживет нас всех. И я согласен с Джоэлем Нили; всегда будет легко найти другого программиста на C, чтобы его поддерживать.

Поскольку программа настолько мала и в основном используется для ввода-вывода и целых манипуляций, я не вижу здесь роли C++. Не стоит лишней сложности.

Answer 2

Я попытался бы поместить его в Free Pascal, но с ограничением по времени. Если это слишком сложно, вернитесь к более позднему используемому (по вашему) языку.

Есть ли способ проверить, соответствует ли новая (портированная или переведенная) версия той же, что и старая?

Answer 3

Я думаю, что перенос 1500 строк кода на любой язык/платформу не должен быть слишком сложным, учитывая тот факт, что все, что вам нужно сделать, это «выполнить заливки» и вычислить контрольные суммы. Лично я бы предпочел C# - он оказывает успокаивающее воздействие на мой разум :), но, учитывая ваше владение C/C++, я бы посоветовал вам пойти с C++ по той простой причине, что C++ - лучший в мире язык ассемблера и выполнит ваши требования в совершенстве. Я думаю, что паскаль - это то, что устарели и новые проекты должны его избегать. Пожалуйста, не стесняйтесь исправить меня, если я ошибаюсь.

Программирование на C - это сложная задача, и для того, чтобы оставить дополнительные возможности для вашей программы, C++ кажется лучшим вариантом. Также не забывайте, что в отличие от C, C++ имеет некоторые очень способные библиотеки, поддерживающие его (STL, Boost и т. Д.).

Answer 4

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

Если это не проблема (например, несколько разработчиков, все одинаково знакомы с одним и тем же диапазоном языков), то я бы оценил время для порта gnu PASCAL для времени, например. порт Perl и перейдите на целевой язык, который займет меньше времени на использование.

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

Answer 5

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

Нет смысла прибегать к языку сценариев (потому что это фрагмент проще), если в компании сидят шесть программистов, сидящих на C++, увеличивая требования к языку при следующем найме.

Лично я возмущаюсь Perl, потому что, ну, синтаксис слегка криптографический. Кроме того, это не такой «корпоративный» язык, особенно не здесь, и за пределами системного блока Unix трудно найти людей, которые действительно разбираются в нем (*)

Обратите внимание, что это всего лишь запись с моей текущей точки зрения, которая в основном связана с программистом в небольшом магазине с крупными коммерческими клиентами, которые заставляют их практиковать на нас. YMMV.

(*) webdevels делаю в основном ASP.NET здесь.