воскресенье, 27 февраля 2011 г.

Лисп - это круто!

Если посмотреть на код в предыдущем моём посте, а также на код love5an'а, то лисповых преимуществ перед чистой сишечкой не особо видно. Ну да, что-то за сценой делается. Ну да, можно в рантайме сложную структуру генерировать. Но ведь можно то же самое и на традиционном языке делать, эка невидаль-то! И делают ведь, и давно, и успешно.

Только, если подумать, делают половину лиспа, и делают это плохо.

Вот если бы я не знал лиспа, то максимально мощный доступный мне язык был C++. Ну Java, может быть. Описание железки загнал бы в XML или JSON, инструкции по настройки - ну хз, что бы делал. Скриптовый движок какой-нибудь бы прицепил. Конфигурация из XML/JSON создавалась бы кучей классов, обеспечивающих только самый-самый общий вид структуры. API, соответственно, было бы не прямым и прозрачным, а страшной лапшой из интерфейсов и фабрик. Как эта лапша бы взаимодействовала со скриптами настройки - тоже хороший вопрос.

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

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

Что в случае с лиспом: язык разметки - лисп (DSL, но выглядит-то как лисп). По декларативному описанию обычным лиспокодом генерируются новые типы и код для работы с ними, доступные непосредственно в лисповом скрипте настройки. Т.е. используется одинаково выглядящий синтаксис для написания самой программы, описания подгружаемых структур и кодирования их поведения. И т.к. это происходит внутри одного образа, то устраняются все проблемы со взаимодействием. Какие могут быть проблемы у одного лиспокода вызвать другой лиспокод, даже если он появился позднее первого? Да никаких.

Даже при отладке я могу в slime нажать inspect на объекте, созданном нашей объектной системой, и увидеть его содержимое, которое чрезвычайно похоже на декларативное описание. При этом slime про нашу объектную систему ничего не знает, и это тоже пример того, как крут Коммон Лисп ;)

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

И не надо забывать, что время программиста денег стоит.

4 комментария:

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

    Для тех кто попал в такую ситуацию: при низкоуровневой захардкоженности тоже ситуация такая, что застрелится в пору, но я бы рекомендовал бы всё-таки застрелится от создания монстра, так оно веселее будет ;)

    ОтветитьУдалить
  2. С низкоуровневой залоченностью на железе ничего страшного нет. Просто с новой версией конфигурации железа будет выпускаться новая версия софта - обычная практика ведь, да? :)

    ОтветитьУдалить
  3. Ну с "залоченностью" может и нет, а вот когда в реализациях алгоритмов сплошной хардкод это страшно ... То ли DSL - можно инкапсулировать и минимизировать всё изменяющееся. После применения такого подхода, лень небось уже не позволит работать по другому? ;)

    ОтветитьУдалить
  4. Как-то работал над kdump в линуксовом ядре, и чрезвычайно взбесила необходимость написания развесистого, но абсолютно одинакового кода, который отличался только типами Elf64* и Elf32*. И макросами там сишными ничего сделать нельзя было.

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

    ОтветитьУдалить

Архив блога