dynamic vs static

[juan_gandhi]

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

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

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

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

Comments

[itman.livejournal.com]

Чего-то я не понял как Джава "make uses of multicores" while "c++ doesn't". Что это за интересное такое заявление?

[ivan-gandhi.livejournal.com]

А, это вот о чём. JVM справляется с этим без участия человека; thread запустил, а он уж куда-нибудь попадёт. И доступ к переменным организован, с самого начала, правильным образом.

[itman.livejournal.com]

Ну а плюсовый тред не туда попадет?
PS: а что такое правильный доступ к переменным?

[relyef.livejournal.com]

Сейчас Вы скажете, что Java поддерживает threads affinity :)

[anton-solovyev.livejournal.com]

Долго думал чем мне не нравится Python (vs Java).

Решил, что я -- neat freak и код на Python получается сравнительно messy, а Java enforces some discipline. Perl -- еще хуже.

А, вот еще как можно сравнивать языки: качество стандартных библиотек. С Питоном все время нарываешься на то, что нажал чуть посильнее и оно ползет по швам. Java терпит куда больше abuse. Все время лезет в голову сравнение велосипеда с грузовиком.

[ivan-gandhi.livejournal.com]

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

[nine_k]

Messy? Ужос, ужос. После аккуратного, краткого питоновского кода на многократно более длинный и излишне детальный явский код мне смотреть напряжно.
(А приходится: сопрягаю то и другое.)

[ivan-gandhi.livejournal.com]

Кто б возражал. Я просто видел этот ужас. И сам, хм, одно время занимался переводами с питона на джаву. И видел как пишет Алекс Мартелли. Это стихи.

[anton-solovyev.livejournal.com]

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

[trurle.livejournal.com]

Аккуратность кода не измеряется в байтах.

[faceted-jacinth.livejournal.com]

Егге, по-моему, не видит леса за деревьями. В смысле, несмотря на какбэ критическую установку, всё равно воспринимает язык как данное, а стандартные метафоры -- как непреложные правила (в смысле: я ж могу на чистом С и объекты делать, и динамическую типизацию, никто мне не запретит, потому что эскейпы обязаны быть). И, да, судит о статической типизации по наиболее упёртым представителям, которые пытаются запретить эскейпы.

Я сейчас к одной своей проге простенький скриптовый язык приделываю и у меня всякие полуоформленные мысли в связи с этим появляются. Например: существует заговор: тайное общество поклонников динамически типизированных языков называет "dynamic scope" "lexical scope"-ом, чтобы никто не задумался случайно. Ведь когда пишешь интерпретируемый язык, он натурально получается динамически типизированным и с динамическим scope, это baseline, а чтобы получить lexical (static!) scope нужно приложить неслабые усилия, причём централизованно. Но необходимо, и в том же питоне, кстати говоря, все вызовы обычных функций можно отрезолвить в адреса на этапе компиляции (да они наверное и резолвятся), удивительно если подумать, не правда ли?

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

[ivan-gandhi.livejournal.com]

Ну ведь Стиви, как он ни пыжся, а всё равно остаётся сельским механизатором. Желающим всех научить законам физики.

[nine_k]

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

Вынужден вас разочаровать. Нету там никакого этапа компиляции. Все операторы (в т.ч. class и def) исполняются в runtime. Можно на ходу добавить к классу или конкретному объекту какие угодно новые методы, а старые нагло удалить. Поэтому резолвится всё в момент вызова.

Такая же точно картина в javascript и smalltalk.

Потому с этими штуками так удобно играться интерактивно и так трудно писать к ним осмысленны

[nine_k]

...осмысленный JIT.

[faceted-jacinth.livejournal.com]

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

Where is your God now?

[faceted-jacinth.livejournal.com]

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

[cmm.livejournal.com]

Такая же точно картина в javascript и smalltalk.

не везде, насколько я знаю.
из спецификации соответствующих языков ничего подобного точно не следует.

[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 обращения, можно сразу по адресам. Как-то так, я этого ещё не делал.

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

[cema.livejournal.com]

Скобку закрой. :-)

[yosefk.livejournal.com]

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

[ex-chrobin.livejournal.com]

если я ничего не путаю, гарвардская архитектура предполагает immutable code.

[ex-chrobin.livejournal.com]

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

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

[mikkim08.livejournal.com]

Надо ему подсказать как-то что ли.
А то пропадает человек.

[mikkim08.livejournal.com]

Я работал с одним софтом, который был написан на Джаве, но следующим образом:

Были классы -- чистые value objects. Просто структуры данных с конструкторами и аксесорами. Были классы -- чистые команды. Просто функции.

Но это внутри.

А сверху в качестве API выдавались обычные классы, совмещающие state и behavior.

Я спросил у тех мужиков:
- Вы с "Си" что ли портировали ?
- Нет, - говорят. С нуля так писали. Просто ООП мы тут не любим, но раз народу нравится -- сделали.