Книга FPS № 29 2014

Название: FPS №29 2014
Автор: Коллектив
Страниц: 36
Формат: PDF
Размер: 29.24 MB
Качество: Отличное
Язык: Русский
Жанр: Компьютерный
Год издания: 2014
Сегодня в журнале FPS поговорим о разных языках програмирования. Парадоксально - языков программирования существует великое множество, но их почему-то всегда не хватает. Всегда найдется предметная область, в которой существующие языки плохо применимы, и программисты придумывают еще один, чтобы компенсировать это досадное упущение. Или бывает так, что в старых языках становится трудно выразить какие-то только что изобретенные идеи и концепции- и создается новый язык, в котором эти концепции «встроены» изначально.
Поэтому я никогда не понимал тех, кто считает, что языков уже достаточно, и что создавать новые - это «велосипедастроение». Языков никогда не бывает достаточно, потому что нет ни одного языка, который бы покрывал абсолютно все задачи и потребности. Такая ситуация возникла и у меня, когда пенадобился скриптовый язык, который можно было бы использовать в D. Поскольку для этого реализация языка должна иметь С-интерфейс, выбор был невелик:
1. Lua или Python. Я уже имел опыт использования Lua в С++, поэтому этот вариант казался самым очевидным. Для Lua существует динамическая D-привязка через Derelict, а также враппер LuaD, обеспечивающий тесную интеграцию языка с системой типов D. Выглядело это все достаточно привлекательно, но, вопервых, LuaD не имеет поддержки последних версий Lua, а, в вовторых, у меня свое собственное видение того, как должна работать скриптовая система. Программист должен иметь возможность загружать много отдельных скриптов из различных файлов, и вызывать из них те или иные функции. Скрипты должны быть многоразовыми, а не просто «загрузил скрипт, выполнил, завершил работу». К сожалению, Lua не очень соответствует этим идеям, как и все остальные существующие скриптовые языки: все они тянут одеяло на себя, претендуя на роль основного средства вычислений в программе. Разработчики Python и вовсе не приветствуют встраивание языка в приложение: они рекомендуют писать на Python все приложение целиком.
2. JeweiScript. Это минималистичный язык из семейства фигурных скобок со статической типизацией, чем-то напоминающий D и С++. Как и в случае с Lua и Python, тут тоже имеется Сшный API, так что мне почти сразу удалось привязать JeweiScript к D, и поначалу все казалось идеальным. Однако API этот оказался переусложненным и запутанным- элементарно добавить в язык новую встроенную функцию без построения для этого отдельного класса тут невозможно, а добавление класса, в свою очередь - целая эпопея ... Упростить и автоматизировать этот процесс при помощи каких-то «умных» шаблонов мне так и не удалось. Тут прояснилось еще одно требование к скриптовой системе: удобный API, позволяющий взаимодействовать с D. Трудно ожидать такого от С-библиотек, при взаимодействии с которыми для передачи указателя на функцию нужно предварительно оборачивать ее в extern(C)- в таких условиях можно забыть о замыканиях и ООП. Этому требованию полностью может удовлетворить только язык, сам написанный на О. Но, к сожалению, на тот момент (и на момент написания данной статьи) полноценных скриптовых языков на 02 не существовало (для 01 были языки Monster и Croc - автор последнего упорно не желал переписывать свой проект на 02). Также мне попадалась реализация javascript, написанная на 02, но заброшенная и неподдерживаемая- последними версиями ОМО ее уже не скомпилировать. Поэтому не оставалось ничего другого, как создать свой собственный «идеальный язык» с нуля. Так и появился GScript. Я сторонник С-подобных языков (С, С++, С#, О, Java, javascript), поэтому решил реализовать нечто похожее. Язык реализует императивную, процедурную и модульную парадигмы. Модуль - это файл, в котором определены функции, которые пока являются главными структурными элементами языка. Глобальные переменные языком не поддерживаются -я считаю использование глобальных переменных дурным тоном. При крайней необходимости, аналогичную функциональность можно легко реализовать при помощи функций-примитивов (например, путем взаимодействия с БД или хэш-таблицей). Следуя принципам минимализма, я старался изначально не переусложнять дизайн языка: к примеру, динамическая типизация упростила виртуальную машину - и, вместе с этим, позволила языку бесшовно взаимодействовать со встроенными типами D. Массивы GScript - это обычные массивы D, которые создаются менеджером памяти D и подконтрольны сборщику мусора D. И, чтобы их создавать и ими управлять, не нужно пользоваться какими- то особыми средствами - конкатенация массивов в GScript делается конкатенацией массивов в D, нет никаких лишних уровней абстракции.Строго говоря, функция всегда возвращает значение, даже если в ней не указан оператор return: в данном случае компилятор автоматически вставляет в конец функции возврат значения по умолчанию (Null). Но возвращаемое значение можно не использовать, вызывая функцию как процедуру. По умолчанию аргументы передаются по значению, но можно использовать передачу по ссылке. Что характерно, передача по ссылке возможна в любую функцию, так как ссылочный тип (ref) указывается при конкретном вызове функции, а не при ее объявлении. Сама функция про ссылку ничего не знает и знать не обязана (это один из принципов языка - функция не должна ничего знать о контексте, в котором она вызывается). Вы можете вызвать sqr с передачей аргумента по значению, и ничего особенного не произойдет. Эта особенность языка сугубо экспериментальная: я отдаю себе отчет в том, что такое до меня нигде реализовано не было, и в каких-то ситуациях такой подход может повлечь проблемы. Но с такими ситуациями я пока не встречался, а выгоды от использования ref при вызове могут быть весьма велики. GScript пока не включает ООП, но в нем поддерживается синтаксис вызова функции как метода - для этого используется оператор «:». Именно так работает функция-примитив length, возвращающая длину массива. В комплекте с языком идет небольшая, но растущая стандартная библиотека, в которой имеются функции манипуляции массивами.