dynamic vs static

[juan_gandhi]

Я не собираюсь вступать в эту нонешнюю дискуссию. Просто хочу заметить, что речь идёт о "гарвардской архитектуре" супротив "архитектуры фон Неймана".

В первой данные отделены от кода, и задача программиста состоит в том, чтобы состыковать, хоть и через посредников, данные и код, который их обрабатывает; вот и приходится катать всякие конфигурации, эксэмэли, ентити бинзы; всё для того, чтобы уберечь код от данных. Тогда код можно статически проверить и отлить в бронзе. Чтоб не сломался.

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

Ну а так, наверное, стоит почитать, конечно: Егге устраивает разгром в столице статической типизации

Comments

[cmm.livejournal.com]

существует заговор: тайное общество поклонников динамически типизированных языков называет "dynamic scope" "lexical scope"-ом, чтобы никто не задумался случайно.

ну вот давайте я задумаюсь.
подумал, подумал.
нет, всё правильно.

Ведь когда пишешь интерпретируемый язык, он натурально получается динамически типизированным и с динамическим scope, это baseline, а чтобы получить lexical (static!) scope нужно приложить неслабые усилия, причём централизованно.

что такое "интерпретируемый язык"?  каким образом динамический скоп легче лексического?  какие такие страшные "централизованные усилия"?
(зачем придумывать ещё один недоязык?)

one cannot, в натуре, rightly comprehend the kind of confusion etc.

[faceted-jacinth.livejournal.com]

Интерпретируемый язык это язык, в котором практически нет ничего, напоминающего компиляцию.

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

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

Так вот, dynamic scope получается совершенно естественно: у нас есть один словарь, в котором хранятся значения символов. Определение функции создаёт там символ [имя функции] и запихивает в него тело функции (про параметры пока не думаем), "i = 1" создаёт (или использует текущий) символ i, в котором оказывается объект инт, равный 1, и так далее.

Но при этом (я буду использовать питоновский синтаксис) такой код:

i = 1
def a():
    print i
a()

def b():
    i = 2
    a()

b()

должен печатать 2. Потому что словарь один на всех. Более того, если всё действительно так просто, то а() может изменить i, которую нам бы хотелось считать локальной переменной b(), определение функции с тем же именем как у определённой в каком-нибудь чужом модуле приводит к удивительным результатам и так далее. Dynamic scope плохой!

А дальше начинаются "страшные централизованные усилия". Можно сделать shadowing, но он всех проблем не решает (тот код по-прежнему будет печатать 2, лямбды работать не будут вообще, потому что не будут лексическими замыканиями) и добавляет свои. Следовательно, нужно делать нормальный static scope: для каждой штуки, обладающей лексическим контекстом (функции, например) либо этот контекст сохранять явно и восстанавливать при вызове, прям весь словарь, либо находить все символы, которые при использовании будут обращаться к контексту и честно компилировать их, то есть заменять на fully qualified обращения, можно сразу по адресам. Как-то так, я этого ещё не делал.

(зачем придумывать ещё один недоязык?) -- вот именно за этим, чтобы увидеть, как некоторые привычные вещи оказываются весьма нетривиальными.

[cmm.livejournal.com]

Так вот, dynamic scope получается совершенно естественно: у нас есть один словарь, в котором хранятся значения символов. Определение функции создаёт там символ [имя функции] и запихивает в него тело функции (про параметры пока не думаем), "i = 1" создаёт (или использует текущий) символ i, в котором оказывается объект инт, равный 1, и так далее.

в принятой терминологии это называется global scope.  dynamic scope — это когда можно аккуратно подставлять новое значение глобальной переменной на время выполнения делающей это функции.  как в емаксе, скажем.  отсюда и слово "dynamic", поскольку scope как бы контролируется программой во время выполнения.

Интерпретируемый язык это язык, в котором практически нет ничего, напоминающего компиляцию.

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

(зачем придумывать ещё один недоязык?) -- вот именно за этим, чтобы увидеть, как некоторые привычные вещи оказываются весьма нетривиальными.

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

а теория и практика компиляции языков с lexical scope — это, по сравнению с теми пчёлами, сто раз пройденная неинтересная фигня.

Следовательно, нужно делать нормальный static scope: для каждой штуки, обладающей лексическим контекстом (функции, например) либо этот контекст сохранять явно и восстанавливать при вызове, прям весь словарь, либо находить все символы, которые при использовании будут обращаться к контексту и честно компилировать их, то есть заменять на fully qualified обращения, можно сразу по адресам. Как-то так, я этого ещё не делал.

примирить lexical scope с отсутствием хотя бы чего-то типа перловского "my" — это больно, да.  но это чисто питоновская фигня, я к чему.  если бы Гуидо не был (во времена создания Питона, во всяком случае) позорным неучем, то бабушки были бы дедушками etc.

[faceted-jacinth.livejournal.com]

Я, оказывается, использовал термины почти как они описаны в википедии (http://en.wikipedia.org/wiki/Scope_(programming)#Static_versus_dynamic_scoping), не знаю, насколько это принятая терминология, конечно. Правда, они там включают в него shadowing, ну ладно, спасибо, буду знать.


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


Кстати, Гвидо в момент создания питона уже семь лет был master of science и имел опыт языкотворчества.

[cmm.livejournal.com]

Кстати, Гвидо в момент создания питона уже семь лет был master of science и имел опыт языкотворчества.

удивительно, правда?

Lisp rules, all other programming languages sucks

[trurle.livejournal.com]

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

Re: Lisp rules, all other programming languages sucks

[faceted-jacinth.livejournal.com]

Кто-то, чуть ли не сам Грэхем, писал когда-то, что иксемель лучше подходит для своей предметной области, чем s-expressions. Не помню точно, где и когда, но было. Аргумент базировался в основном на том, что в случае чего придётся ведь искать глюки, а то и пытаться интерпретировать малформед код, а в этих случаях явное указание того, какой тег закрывается, оказывает неоценимую услугу. А код всё равно программы генерят, им не тяжело.

Re: Lisp rules, all other programming languages sucks

[cmm.livejournal.com]

у иксемеля есть предметная область?

Re: Lisp rules, all other programming languages sucks

[faceted-jacinth.livejournal.com]

Да, описание иерархии данных.

Re: Lisp rules, all other programming languages sucks

[cmm.livejournal.com]

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

Re: Lisp rules, all other programming languages sucks

[faceted-jacinth.livejournal.com]

Он не сошёл с ума, он Узрел Истину! Которая состоит в том, что лисп сосёт в большинстве реальных задач, невзирая на всю его приспособленность к работе с нереальными. И вот он пытается что-то с этим сделать, замена сетф на = уже показывает, что его рассудок ясен как никогда (в отличие от рассудков тех, кому это не нравится), хитрый трюк с make-hash, создающим функцию (реверсибл), а не символ, подтверждает впечатление.

Re: Lisp rules, all other programming languages sucks

[cmm.livejournal.com]

я не про Арк, я вообще. :)
совсем человек халтурно писать стал, по-моему.

Re: Lisp rules, all other programming languages sucks

[cmm.livejournal.com]

идея починки "сосания" Лиспа путём рихтовки синтаксиса присваивания, впрочем, тоже очень забавна, да.  нефигово, должно быть, помогает в реальных задачах!

Re: Lisp rules, all other programming languages sucks

[cmm.livejournal.com]

спрашивается, причём тут Лисп?
(в английском языке не следует добавлять 's' к глаголам третьего лица множественного числа, только единственного.  в прошлый раз я счёл это опечаткой).

Re: Lisp rules, all other programming languages sucks

[trurle.livejournal.com]

Мда, в голове образовался copy-paste.
А лисп тут совсем ни при чем, разумеется.

Re: Lisp rules, all other programming languages sucks

[cmm.livejournal.com]

А лисп тут совсем ни при чем, разумеется.

если Вам кажется что причём, то я весь уши.