dynamic vs static

[juan_gandhi]

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

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

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

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

Comments

[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-ы в плохо оттестированном коде.