Причина возникновения нового интереса к проблеме алгоритмической мультиязычности обусловлена накоплением большого объема профессиональных библиотек к столь не популярным сейчас COBOL, FORTRAN, ALGOL. Это особенно актуально для сложных математических расчетов.

Создано ПО, затрачены средства. ПО необходимо дорабатывать. На чем? Язык программирования умер или к нему пропал интерес, что равносильно смерти языка. Вспомним ADA, MODULA...

Существует еще один неприятный момент - одна фирма купила другую и прекратила разработку того или иного продукта (компилятора или транслятора). ПО у разработчиков осталось...

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

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

Поддерживать все существующие языки программирования невозможно, да и не нужно. Реальную финансовую отдачу от внедрения универсальных компиляторов или трансляторов можно получить на двух операционных системах - Windows и Unix. Эти операционные системы являются наиболее популярными, а следовательно, и наиболее доходными.

Касательно DOS. Сложности с реализацией алгоритмической мультиязычности возникают только с взаимодействием программного кода с буфером экрана в режиме эмуляции DOS. Но кто сейчас работает на DOS? На DOS только играют - и то уже редко. Для этого существует Windows 95. Старенький Windows 3.11 рассматривается как нечто неприличное.

Для Windows наиболее популярными языками програмирования можно считать C/C++, PASCAL, BASIC и JAVA. Последний уже несколько лет сдает свои позиции и занимает нишу программирования для Web. C/C++ развивается сам по себе. BASIC развивается благодаря любви Билла Гейтса к своему детищу. Интересная деталь - развитие визуального программирования началось именно с Visual Basic, языка для дилетантов (с точки зрения профессиональных программистов). PASCAL развивается фирмой Borland, и если бы не ее продукт Delphi, она бы упала еще ниже. В этот список можно было бы включить FORTRAN, но на практике существуют проекты, пришедшие с Unix.

Для Unix в наибольшей степени характерны C/C++, PERL, FORTRAN, JAVA. Медленно стал появляться интерес к COBOL. С/С++ и JAVA имеют тот же интерес, что и на Windows. PERL исключительно продвигается его фанатами. FORTRAN и COBOL остались с еще незапамятных времен.

С моей точки зрения, нет плохих языков программирования, есть плохие реализации и собственные коммерческие интересы фирм-разработчиков.

Идея по созданию универсальных интерпретаторов или компиляторов уже возникала на UNIX, но дальше конвертаторов типа C в PASCAL и обратно не пошла. Сказались следующие основные причины:

1. Не появилось достаточно удачного коммерческого продукта, который бы агрессивно внедрялся и рекламировался на рынке программного обеспечения как Visual C++ от Microsoft или Java от Sun. В качестве своеобразного языкового стандарта со временем стал выступать язык С/С++.
2. Нежелание крупных фирм терять возможность поставки пользователям нескольких продуктов вместо одного универсального. Это бы резко снизило прибыль от продаж и еще более усилило конкуренцию на рынке программного обеспечения.
   На данный момент продукты Borland C++ Builder и Delphi позволяют использовать *.dcu-файлы, построенные один в одном. Речь идет о той же "совместимости" C++ и PASCAL. И это все?
   Microsoft, напротив, увеличивает различие между языками, создавая необходимость приобретения двух продуктов - Visual C++ и Visual Basic - для "нормальной комфортной работы". Visual C++ обладает прекрасным кодом и максимальной совместимостью с Windows, но с не менее безобразным окном свойств и созданием переменных-указателей на ресурс. Visual Basic великолепно приспособлен для работы с интерфейсом. Отсутствие указателей и неполная поддержка объектно-ориентированного программирования приводит к необходимости использования DLL, созданных в Visual C++, и создания интерфейса на Visual Basic с вызовом полученной DLL. Интерфейс функций DLL формируется без передачи параметров-структур, содержащих ссылки. Есть еще одна замечательная тонкость - Visual C++ - компилятор, а Visual Basic - интерпретатор...
3. Сложность реализации эффективного алгоритма и наличие большого количества клонов с несовместимыми языковыми расширениями. Обычно фирмы стремятся поддерживать только синтаксис самого языка. В остальном фирмы руководствуются собственными представлениями о программировании. Сразу же возникают проблемы с семантикой языка программирования и их совместимостью.
   Средства разработки могут иметь принципиально разные архитектуры построения ПО. Это особенно четко просматривается на примерах Microsoft Visual C++ и Borland C++ по сравнению с C++ Builder (Delphi).
   За последние годы программирование все больше сводится к использованию библиотеки классов. Среди них выделились две библиотеки: MFC (Microsoft Foundation Classes) Microsoft и OWL (Object Windows Library) Borland. Эти библиотеки в принципе не совместимы.
   Наибольшее развитие получила библиотека MFC, т.к. она разработана фирмой-разработчиком Windows. Многие утилиты Windows созданы на основе этой библиотеки. MFC в наибольшей степени адаптирована к Windows. Многие средства разработки ПО под Windows на С++ основаны на применении MFC.
4. Сложность совместимости типизируемых языков программирования с нетипизированными. Например, BASIC был изначально создан как нетипизируемый язык (Visual Basic имеет типизируемые переменные), а PASCAL исключительно как типизируемый.
   При обсуждении моделей реализации мультиязычности это первый вопрос, задаваемый оппонентами. В большинстве реализаций пакетов разработки ПО существует тип Variant (CVariant, TVariant). Если ведется конвертация из нетипизируемого языка программирования, то тип переменной выставляется как Variant.
5. Появление новой модели развития коммерческих продуктов. Вместо поддержки нескольких языков программирования на одной платформе в одном средстве предлагается вариант одного языка программирования для разных платформ. Эту модель используют для продвижения на рынке языков С/С++ и JAVA.
6. Появление технологий внедрения объектов: OLE, OCX и ActiveX.

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

После рассмотрения причин попробуем сформулировать основные пожелания к реализации будущего универсального языкового компилятора или транслятора:

1. поддержка максимально возможного количества алгоритмических языков;
2. полная поддержка объектно-ориентированного программирования;
3. возможность наращивания типов конвертируемых лексем.

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

Возможны несколько основных способов поддержки мультиязычности:

1. Автоматическое распознавание лексем по ходу анализа кода программы.
2. Обработка опций языкового блока (команды - старт/финиш нового языка).
3. Принадлежность лексемы к языку определяется расширением файла.

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

Наиболее типичные особенности языков программирования (не рассматривая семантические различия языков программирования):

1. Возможности совпадения названий файлов и классов в них.
2. Поиск файлов библиотек.
3. Распознавание заглавных и строчных символов.
4. Реализация обработки ошибок.
5. Особенности отладчика и его опции.

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

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

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

Сергей СОКОЛОВ
(БГУИР),
sokol@belcaf.minsk.by