Общее понятие о стилях программирования

Когда нужно использовать различные стили и как они взаимодействуют?

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

Пример. После того как была решена задача, можно ли разложить на множители многочлен x² + (p - 1) над полем вычетов по модулю p, студенты глубоко задумались над вопросом, можно ли разложить многочлен x² + 2 в поле по модулю 3.

В связи с этим дадим некоторые советы по практическому применению общих принципов.

Внимание!

Не воспринимайте то, что дано ниже, как шаблоны! За шаблонами идите по другим адресам.

1. Если у Вас появляется много структурных или (не дай Бог) неструктурных переходов либо все время приходится присваивать значения признакам, а затем их проверять, посмотрите, нельзя ли выделить модуль в автоматном стиле.
2. Если Вы начинаете думать о задаче как о вычислении (не обязательно над числами), пользуйтесь структурным программированием.
3. Если Вы намерены переложить понравившуюся Вам нечисленную (например, алгебраическую, топологическую или логическую) теорему в алгоритм для решения Вашей задачи, подумайте о функциональном стиле.
4. Если у Вас каждое следующее значение требует немногих данных, но различные значения обращаются к одним и тем же, даже не пытайтесь программировать рекурсивно, рекурсивное описание можете сохранить в качестве документации к программе, а саму программу пишите в терминах циклов и массивов.
5. Если данные строго подразделяются на ветви, используемые разными последующими значениями, часто лучше писать рекурсивно.
6. Если Вы начинаете смотреть на данные как на активные единицы, которые взаимодействуют между собой, воспользуйтесь объектно-ориентированным программированием.
7. Если в предыдущем случае объекты в том виде, как они предоставляются современными системами программирования, не подошли, воспользуйтесь каким-либо пакетом^{7К несчастью, языки семейства SIMULA, поддерживающие квазипараллельную работу, безнадежно морально устарели.} для организации квазипараллельной работы в условном времени и программируйте от событий.
8. Если Вам нужно преобразовывать сложные структурированные тексты в другие тексты, не поленитесь воспользоваться Рефалом (или новым языком сентенциального конкретизационного программирования, если он уже появится к тому времени, когда Вы будете это читать).
9. В частности, если исходные данные или конечный результат имеет формат символьного файла, совершенно неудобоваримого для стандартных процедур ввода/вывода используемой Вами основной системы программирования, пишите препроцессоры или постпроцессоры на Рефале (либо, в крайнем случае, на Perl).
10. Если Вы путаетесь в многочисленных условиях, когда удача либо неудача порою проявляется после нескольких попыток и неясно, куда нужно вернуться, посмотрите, нельзя ли проверку условий запрограммировать на языке Prolog^{8Но, если остальные преобразования хоть сколько-нибудь не сводятся к подстановке новых значений в хорошо организованные иерархические структуры, не пытайтесь делать на нем основные вычисления и преобразования! Вызов модулей на других языках даже через файлы окупится. Тем более это важно потому, что те, кто слишком рьяно стремятся преодолеть нелогичности "логического программирования", быстро оказываются безнадежно инфицированными Prolog-хакерством, а оно неизлечимо и отупляет.} (или на новом языке сентенциального унификационного программирования, если он уже появится к тому времени, когда Вы будете это читать).

О сочетании стилей

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

Дадим некоторые практические рекомендации по сочетанию стилей.

1. Структурное и автоматное программирование нужно как можно жестче разделять на уровне модулей. Вопрос о языковой совместимости и интерфейсах здесь не возникает, поскольку оба они реализуются стандартными средствами традиционных языков.
2. Две ипостаси структурного программирования также нужно как можно жестче разделять средствами модульности.
3. Параллельная ипостась автоматного программирования в настоящий момент может быть реализована практически только последовательными средствами, воспользуйтесь системой моделирования в условном времени.
4. Событийное программирование стоит выделять в самостоятельные модули либо целиком выносить в Perl-программы.
5. В настоящий момент имеется целый ряд языков, основанных на идеях функционального программирования и продолжающих тенденции языка LISP на более современном уровне. Они имеют интерфейсы с С++ и Java, так что для написания модуля в функциональном стиле внутри большой, в основном традиционной, программы лучше воспользоваться Ocaml или Haskell.
6. Common Lisp обладает достаточно удовлетворительно проработанными интерфейсами с C++. Эти интерфейсы могут эффективно использоваться профессионалами. В отношении же концептуальной целостности Lisp остается несравненным, и, если значительная часть Вашей программы функциональная, стоит пользоваться им.
7. Common Lisp обладает удовлетворительно проработанными интерфейсами с Prolog. Но автор не считает разумным писать программу, соединяя функциональный стиль и унификационную ипостась сентенциального, и будет благодарен за примеры противного, если такие найдутся.
8. Тем не менее указанный в предыдущем пункте интерфейс полезен, если Вы решили использовать задел, накопленный на одном из двух упомянутых языков, в новой программе, написанной на другом. Но будьте готовы к тому, что концептуальные несовместимости могут в некоторый момент оказаться хуже необходимости переписать используемые программы по-своему.
9. Хороших интерфейсов с Рефалом нигде нет. Но, несмотря на это, есть один практический совет. Системы ввода/вывода Common Lisp и Prolog настолько неудобны и морально устарели, что написание пре- и постпроцессоров обработки входных и выходных данных на Рефале (либо Perl) окупается, а в Lisp или Prolog есть смысл пользоваться лишь простейшими возможностями ввода и вывода, принимающими предварительно обработанные и полностью укладывающиеся в структуру языка данные и выдающими их также без учета пользовательского формата.