От редакции: Коммерческий APL (Джонатан Бармен)
Я был очень впечатлен собранием Британской Ассоциации APL в инвестиционном банке Morgan Stanley. Мы увидели команду APL разработчиков, писавших системы критически важные для успешного бизнеса. Как скорость разработки, так и скорость выполнения подобных систем крайне важны, но APL и производный от него язык A успешно справлялись с этой задачей.
Разработка А внутри Morgan Stanley просто удивительна. У них есть небольшая команда программистов, создающих язык, который должен быть лучшим из лучших на рынке коммерческих приложений. Новые возможности могут быть включены в этот язык очень быстро, особенно учитывая то, что им занимается лишь узкий круг людей.
Коммерческая реализация APL не может не включать каких-либо интересных возможностей. Однако, каждый разработчик APL-систем, использует свой собственный подход, а процесс включения в язык новых возможностей очень сложен и требует длительного исследования требований пользователей и продолжительного анализа дискуссий на пользовательских форумах, при это всегда стоит проблема совместимости с новыми версиями. Но ведь очень важно, чтобы существующие пользователи системы могли без проблем запускать старый код на новых реализациях. Поэтому разработчики стремятся включать только те возможности, которые будут интересны как можно более широкой аудитории пользователей.
Главные цели разработчиков A в Morgan Stanley отличаются от целей разработчиков коммерческих APL-систем. Очень интересно наблюдать за тем, какие возможности они добавляют в язык, а какие убирают. Как бы вы отнеслись к отсутствию возможности безусловного перехода на метку? Фил Ласт и Жерар Лангле в своих статьях в нашем журнале показали как они ненавидят безусловные переходы, так что они были бы только рады этому, но большая часть программистов на APL, думаю, сочла бы этот шаг неправильным. Я, например, не могу себе представить успешную реализацию APL без оператора безусловного перехода.
Некоторые возможности А я был бы рад видеть в новом стандарте APL. Например, я испытываю острую необходимость в возможности группировки имен, пришедшей из APL2 и развитой в А, где она была названа «контекстами». Дик Боуман в своей статье «Seize the Time» был крайне разочарован тем фактом, что для APL создано очень малое количество тулкитов. Как мне кажется, это является следствием отсутствия возможности собрать группу функций в независимую библиотеку. В языке С любой может купить библиотеку функций, распространяемую в виде объектного файла и использовать ее, однако, не видя исходного кода. В стандартном APL же функции могут быть «заблокированы», но эта возможность не обеспечивает особой безопасности. При использовании в APL сторонних объектных библиотек возникают проблемы, например, при «падении» интерпретатора важным вопросом будет: вызвала ли это «падение» сторонняя библиотека, или же это ошибка самого интерпретатора. Хорошая реализация библиотек в APL может стимулировать продажу и создание множества тулкитов.
Реализация А существует только внутри Morgan Stanley, никто другой не может купить ее, поэтому интерес к нему несколько академичен, однако, мы можем извлечь важные уроки того, каким должен быть язык, способный решать реальные коммерческие задачи, и какие возможности должны быть включены в будущие версии APL.
В последнем номере Vector я обещал вам обзор Windows-интерфейса системы APL*PLUS II/386. Я хотел сравнить эту реализацию с Dyalog APL/W, которая, как я знаю, использует несколько другой подход при интеграции с Windows. Также я надеялся увидеть несколько интересных идей, которые могли бы помочь разрешить сложности программирования под Windows. К сожалению, меня постигло серьезное разочарование. Систему APL*PLUS II/386 можно заставить работать под Windows, причем будут доступны все Windows-функции, однако для этого потребуется куда больше сил и терпения чем для привычного программирования на APL. Обзору Рэя Кеннона помешало то, что его компьютер имеет 4 мегабайта памяти и он работал на Windows 3.0, а не 3.1. Как нам обещают, следующая версия APL*PLUS II/386 5.0 будет гораздо проще в использовании, однако пока что интерфейс в этой APL-систем слишком закручен и сложен для нормального использования.
Этот перевод в pdf
Комментариев нет:
Отправить комментарий