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

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

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

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

1)

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

2)

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

3)

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

Когда рассматривался вопрос, стоит ли делать трансляторы, лучшие московские программисты аргументировали, что делать этого не стоит. Они разработали исключительно совершенную систему разделения труда при кодировании на уровне машинных команд, когда программист писал все в "содержательных обозначениях", а техники (чаще всего девушки) чисто механически составляли таблицы и переписывали содержательные обозначения в двоичные коды. Система изложена в книге [7]. Поэтому они заявили, что трансляторы не нужны, машинные программы девочки напишут.

Но поднялся молодой и считавший себя весьма знающим функционер из научного отдела ЦК и заявил примерно следующее:

— Я приоткрою секретную информацию. У нас сейчас создается машина (это была БЭСМ-6), которая будет выполнять миллион команд в секунду. Это что же, вам девочки миллион команд напишут?

4)

В идеале это так. Но в жизни не всегда методика опирается на метод, чаще — на традиции.

5)

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

6)

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

7)

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

8)

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

9)

Но, если остальные преобразования хоть сколько-нибудь не сводятся к подстановке новых значений в хорошо организованные иерархические структуры, не пытайтесь делать на нем основные вычисления и преобразования! Вызов модулей на других языках даже через файлы окупится. Тем более это важно потому, что те, кто слишком рьяно стремятся преодолеть нелогичности "логического программирования", быстро оказываются безнадежно инфицированными Prolog-хакерством, а оно неизлечимо и отупляет.

Содержание раздела