среда, сентября 26, 2007

И еще немного про скрипты

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

Но есть еще одна причина, по которой люди используют скрипты — расширяемость программ. И эта проблема уже больше психологическая. Программист, как и любой умник, хочет написать что-то клевое и универсальное (движок), чем потом можно будет как угодно рулить из скрипта: «Смотрите, вот вам exe-шник, а работать он будет так, как мы ему напишем в скриптах» (вернее, «Смотрите, какой я умный, умею создавать гибкие решения»). Внимание, вопрос! А не является ли ваш скрипт, по сути, очередным exe-шником или dll-кой? Не добьетесь ли вы такой же гибкости просто написав модуль к программе?

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

Soft coding — не лучшая замена hard coding-у. Чем отличается код скрипта в отдельном файле от обычного модуля программы? Тем, что красивше? Значит у вас недостаточно выразительный основной язык. Тем, что его можно динамически загрузить в рабочую программу? А разве обычный модуль нельзя?

В общем, пишите всю программу на нормальном языке и изучите возможности динамической загрузки кода. И тогда «болезнь чрезвычайной гибкости при помощи скриптов» покинет вас.

PS: еще рекомендую почитать (не столько про скрипты, сколько про липовую расширяемость за счет «правильной» архитектуры): The Mythical Business Layer.

17 комментариев:

admix комментирует...

А Вам не кажется, что для написания "скриптов" можно использовать труд менее квалифицированных кадров, которые не владеют такими языками как С++ или OCaml? (не совсем согласен, но мнение распространенное)

Vladimir Shabanov комментирует...

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

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

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

Анонимный комментирует...

А какая разница прикручивать ли к С++ питоньи скрипты или к окамлу сишные библиотеки? По сложности одинаково по другим показателям связка С++ и Python может и получше оказаться. Питон все-таки проще окамла.

Vladimir Shabanov комментирует...

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

В случае питона, в скрипты надо прикручивать специфичные для проекта плюсовые функции, а основу проекта писать на менее продуктивном языке.

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

Анонимный комментирует...

Одним из плюсов скриптов является то, что их не надо компилировать и в случае необходимости можно править код прямо на лету.
Буквально недавно при развертывании сервиса на asp.net вылезло некольеко некритичных, но неприятных проблем, которые в случае скриптового языка решились бы правкой на ходу.
А так решилось через неделю после возращения из командировки.

Vladimir Shabanov комментирует...

> Одним из плюсов скриптов является то, что их не надо компилировать ...

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

> ... и в случае необходимости можно править код прямо на лету

Точно, только с модулями можно делать все то же самое. При этом "скрипт" еще и автоматом скомпилируется, что избавит от потери времени на отладку опечаток ;)

Анонимный комментирует...

>В реальности скрипт компилируется: не текст ведь запускается.
Интерпретируемых скриптов не бывает?

>Сделать автоматическую компиляцию модулей программы с последующей загрузкой -- дело, максимум, нескольких часов.

Visual Studio 2005 на сервер поставить? Не серьезно.

Скажу более детально про ситуацию, о которой упоминал.
Ставили ASP.NET сервис в закрытую внутреннюю сеть предприятия.

Разрешения на подключение ноута к сети нет, на установку программ сверх плана развертывания тоже.

На ноуте проблемы, которые есть на сервере, не воспроиводятся.

В итоге получается цепочка поменяли код, собрали на ноуте, через внешний носитель внесли в интранет, поствили нас сервер, проанализировали результат, опять поправили код на ноуте...
Очень непроизводительно.

Vladimir Shabanov комментирует...

Перед интерпретацией скрипты все равно компилируются в байткод, это просто незаметно.

Всю VS ставить не надо, нужен только компилятор (он, вроде, бесплатен).

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

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

Анонимный комментирует...

>Всю VS ставить не надо, нужен только компилятор (он, вроде, бесплатен).

Никто не даст ставить на сервер не согласованный софт, который, очевидно, не используется для выполнения основной задачи.

Vladimir Shabanov комментирует...

Т.е. интерпретатор питона, перла и пр. поставить можно, а компилятор C# -- нет.

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

Vladimir Shabanov комментирует...

Продолжение обсуждения с shadow-aka-hf смотрите на
shadow-aka-hf.livejournal.com/23764.html.

Алексей комментирует...

>Т.е. интерпретатор питона, перла и пр. поставить можно, а компилятор C# -- нет.

Прикол в том, что компилятор C# есть везде, где установлен .NET Framework.

Vladimir Shabanov комментирует...

> Прикол в том, что компилятор C# есть везде, где установлен .NET Framework.

)))

Анонимный комментирует...

Владимир, а что скажешь по поводу Lua? Сталкивался ли и как относишься? Вещь мегапопулярная у разработчиков игр. Млм здесь ты остаешься верен себе и считаешь что C/Haskell покроет это?

Vladimir Shabanov комментирует...

Про Lua я много сказать не могу. Язык достаточно простой, в тоже время есть замыкания, coroutines и еще какие-то вкусности. Т.е. будет, наверное, получше С.

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

Он легко встраивается в С. Так что для программ, написанных на С/С++ вполне подходящий вариант, чтобы хоть как-то поднять уровень разработки (и при этом упростить ее, т.к. Lua все-таки проще C++ будет).

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

Анонимный комментирует...

Есть такое понятие как "ад DLL", вы когда нибудь на него натыкались? когда кладёшь новую dll а хост программа и говорит - фигвам. иногда до белого коления доводит. на скриптах же "плагинизация" реализуется значительно проще

Vladimir Shabanov комментирует...

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

Если скрипты делаются на хаскеле/кемле, то компилер/линкер не даст вставить скрипт, несовместимый с программой. Так что dll-hell-а не будет.