dynamic vs static

[juan_gandhi]

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

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

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

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

Comments

[nine_k]

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

[ivan-gandhi.livejournal.com]

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

[mikkim08.livejournal.com]

И видел как пишет Алекс Мартелли. Это стихи.

А например ? (люблю красивый код смотреть)

[ivan-gandhi.livejournal.com]

def allstrings(alphabet):
    yield ''
    for astring in allstrings(alphabet):
        for letter in alphabet:
            yield astring + letter 

[nine_k]

чума! 8-)

[glader.livejournal.com]

А где еще его красивости можно посмотреть?

[ivan-gandhi.livejournal.com]

В гугловской codebase?

[glader.livejournal.com]

Если ты про http://code.google.com/search/#q=Martelli , то там я ничего внятного не нашел. Будь добр, объясни чуть поподробнее, если не трудно.

[ivan-gandhi.livejournal.com]

:) Я имел в виду внутреннюю codebase...

[anton-solovyev.livejournal.com]

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

[nine_k]

Всерьёз не проверял? Настолько не проверял, что почему-то Google AppEngine из всех языков поддерживает именно питон? :)

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

[anton-solovyev.livejournal.com]

В широте использования сомнений нет, на Питоне тут стоим.

Однако, например, при попытке всерьез использовать что-то типа xmlrpclib или SimpleXMLRPCServer оно начинает позорно трещать по швам.

Деталей не помню, но осадочек остался.

[nine_k]

Да, не все библиотеки одинаково толковы :( Притом xmlrpc как-то особенно крива, но даже и urllib-ы всякие, без которых вроде бы никуда, местами не без косяков.

Это я почему-то счёл, что "всерьёз неикто не проверял" у вас про коллекции и прочие базовые вещи.

[trurle.livejournal.com]

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

[nine_k]

Беда в другом: число строк, которые человек способен удержать в сознании, невелико, и потому число строк, которые можно написать / отладить за данное время, не сильно отличается от языка к языку (хотя, конечно, разные языки отличаются уровнем многословия: на java можно за час успеть написать 20 осмысленных строк, а на J — одну-две).

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

А вот и не жаль

[trurle.livejournal.com]

число строк, которые человек способен удержать в сознании, невелико, и потому число строк, которые можно написать / отладить за данное время, не сильно отличается от языка к языку (хотя, конечно, разные языки отличаются уровнем многословия: на java можно за час успеть написать 20 осмысленных строк, а на J — одну-две).
Это утверждение неверно. Ограничено число концепций и связей, которые человек может удержать в голове, многословность же или сжатость изложения этих концепций имеет совершенно второстепенное значение. Более того, подробное и однозначное изложение может быть преимуществом.
Потому чем компактнее язык упаковывает понятия, тем он больше (потенциально) увеличивает производительность разработки
Вам должен был понравиться APL в его силе и славе, со спецсимволами для операторов. Жаль только что не все программисты разделяют Ваши вкусы.

Re: А вот и не жаль

[nine_k]

О прямом наследнике APL я упомянул выше, под именем J :)

Связи возникают между всеми объектами, которые участвуют в исходном коде. Не все из них вызывают одинаковое умственное напряжение, но все вызывают ненулевое. Разумеется, над закорючками APL-образных языков приходится думать в среднем больше на едимницу длины кода. Но это, увы, не значит, что конструкции вида List<Pair<int, String>> lst = new ArrayList<Pair<int, String>>() проходят для мозга по той же цене, что lst = [].

Re: А вот и не жаль

[trurle.livejournal.com]

Но это, увы, не значит, что конструкции вида List

[Error: Irreparable invalid markup ('<pair<int,>') in entry. Owner must fix manually. Raw contents below.]

<i>Но это, увы, не значит, что конструкции вида List<Pair<int, String>> lst = new ArrayList<Pair<int, String>>() проходят для мозга по той же цене, что lst = [].</i>
Разумеется, не по той же. Понять что именно скрывается за конструкцией lst = [] гораздо сложнее чем List<Pair<int, String>> lst = new ArrayList<Pair<int, String>>().
Потому что lst = [] может обозначать тучу разных вещей, о природе которых надо задумываться глядя на эти криптическую запись.

Re: А вот и не жаль

[nine_k]

Задумываться надо и там, и там. Но о разном. Иногда выгоднее одно, иногда другое.
Мне мои задачи расчёта движения денег было проще писать на питоне, и на ошибки типизации я как-то вроде не нарывался. Самое распространённое было — NPE в личине "Object 'None' has no methos %s" или NameError-ы в плохо оттестированном коде.