Прежде всего, если вдруг ты до сих пор не читал эту статью, погляди сюда:
http://lib.ru/ANEKDOTY/non_pas.txtТолько не забывай, что это - всего лишь шутка, и не воспринимай слишком серьезно.
Это было бы интересно применить, потому что есть некоторые задачи, которые решаются по 2-3 недели. Хотя конечно задача может в принципе не распараллеливаться.
Разумеется, не каждый алгоритм удается распараллелить. Но даже в худшем случае объектный подход тоже может помочь. Дело в том, что состояние объекта несложно сохранить в файле либо в базе данных, а потом при необходимости восстановить. Таким образом, при решении громоздкой задачи ты можешь установить контрольные точки, в которых сохранять состояние нужных объектов, и в случае сбоя начинать вычисления не с нуля, а с последней контрольной точки. Для задачи, которая решается 2-3 недели, такой подход может сохранить уйму времени.
У меня есть некоторые подозрения насчёт оптимизированности фортрановских программ. Я согласен с тем, что фортрановские программы долго отлаживались, но я думаю, что это касается небольших и часто применяющихся программ. А большие программы всё равно отладить трудно и тут может возникнуть обратный эффект. Особенно, если задачи не распространённые, узко специализированные, программисты бОльше специалисты в физике процессов, а не в программировании.
Вопрос сложный. Во-первых, долгое использование программы не гарантирует отсутствие ошибок. По этому поводу вспомнилась очень поучительная история из моей практики, но она немного оффтоп в данной теме.
Во-вторых, FORTRAN - весьма примитивный язык, чуть выше уровня ассемблера. Поэтому компиляторы дают очень компактный и эффективный код. Конечно, от глупостей при программировании это не спасает, но накладные расходы весьма низки и программы обычно работают очень быстро. Так что тягаться в скорости с программами на FORTRAN непросто.
Далее. Если я всё-таки буду работать на фортране, то наверное от меня потребуется изучение предыдущего кода.
1. Если бы этот код был бы написан с помощью ООП то не проще ли мне было бы это делать?
Без всякого сомнения хорошо написанная ООП-программа понятнее хорошо написанной структурной программы. Однако, как говорится в статье, ссылку на которую я привел выше,
закоренелый настоящий программист может написать фортрановскую программу на любом языке.
При желании можно написать отвратительную ООП-программу и изящную структурную.
Также немаловажна общая культура программирования в коллективе, в котором тебе предстоит работать. Если каждый модуль предваряется кратким описанием, из которого можно выяснить его назначение, входные и выходные параметры и принцип работы, может и не потребоваться чтение его исходного текста, если сам модуль тебя устраивает.
2. Но всё-таки он написан не с помощью ООП. И тогда как меня тут могут выручить современные технологии в программировании?
Повторюсь, для того, чтобы твой модуль можно было использовать в FORTRAN-программе и чтобы самому можно было использовать готовые модули FORTRAN, вовсе не обязательно самому писать исключительно на FORTRAN. Достаточно аккуратно соблюдать межмодульные интерфейсы, и ты волен выбрать любой язык, который тебе нравится.
Далее. Наверняка программисты довольно сильно продвинулись в программировании математических задач, о которых не знают программисты с завода. Можно ли тут найти средства для качественного рывка. Например класс по обработке больших чисел, комплексных чисел.
Вообще-то по части вычисления формул FORTRAN достаточно хорош, поскольку изначально был под это заточен (даже само название языка означает FORmula TRANslation). Те же комплексные числа встроены в него изначально, за что его до сих пор так любят инженеры. Вот по части нечисленной обработки и изощренной логики дело обстоит куда хуже.
