Квинтессенция языков программирования.

[nondeterminism]

AlexDem в сообщении #1012667 писал(а):

Что значат эти "futures"? Реализован ли конкретный механизм конкурирующего доступа к данным?

фьючер -- это объект, возвращаемый асинхронной посылкой сообщения. Он изменяется на результат, вычисления, когда вычисление выполнится. Конкретный механизм конкурирующего доступа к данным реализован виде модели акторов. Первую часть вашего сообщения я вообще не понял, это набор слов какой то.

-- 09.05.2015, 09:17 --

AlexDem в сообщении #1012667 писал(а):

Чем хороши все значения в виде объектов? Это ведь значит, что наложено ограничение: скалярные типы запрещены. Если ограничение не привносит преимуществ, то зачем оно нужно.

О каких ограничениях Вы говорите? Кто Вам мешает использовать объект в качестве примитива?

Цитата:

Т.е. а где код нельзя представить в виде дерева? Потому как любое выражение можно. Модифицируемость этого дерева - а синтаксис языка не определяет это дерево однозначно?

Речь идет о возможностях интроспекции и рефлексии.

[AlexDem]

nondeterminism в сообщении #1012669 писал(а):

Первую часть вашего сообщения я вообще не понял, это набор слов какой то.

Возможно, это проблема интерпретатора.

nondeterminism в сообщении #1012669 писал(а):

фьючер -- это объект, возвращаемый асинхронной посылкой сообщения. Он изменяется на результат, вычисления, когда вычисление выполнится.

Это не ново.

nondeterminism в сообщении #1012669 писал(а):

Конкретный механизм конкурирующего доступа к данным реализован виде модели акторов.

Вы отвечаете не на тот вопрос. Как конкретно организовать безопасное изменение одного объекта в двух конкурирующих процессах? Модель акторов говорит только "с помощью обмена асинхронными сообщениями". Это значит - "сделайте сами что-нибудь".

-- менее минуты назад --

nondeterminism в сообщении #1012669 писал(а):

О каких ограничениях Вы говорите? Кто Вам мешает использовать объект в качестве примитива?

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

nondeterminism в сообщении #1012669 писал(а):

Речь идет о возможностях интроспекции и рефлексии.

Самомодифицирующиеся программы? Ну не пробовал, не буду ничего говорить тогда. Хотя мне кажется, что с параллельными вычислениями такое подружить очень сложно - как искать ошибку, если перед глазами нет даже полного текста программы.

[nondeterminism]

AlexDem в сообщении #1012671 писал(а):

nondeterminism в сообщении #1012669 писал(а):

Конкретный механизм конкурирующего доступа к данным реализован виде модели акторов.

Вы отвечаете не на тот вопрос. Как конкретно организовать безопасное изменение одного объекта в двух конкурирующих процессах? Модель акторов говорит только "с помощью обмена асинхронными сообщениями". Это значит - "сделайте сами что-нибудь".

А Вы что же хотели, чтобы за Вас язык все сделал? Используются обычные средства, блокировки. Преимуществом модели акторов тут является то, что такая система может автоматически выявлять дедлоки. Между прочим, единственная возможная реализация параллелизма основана именно на модели акторов, она собственно и используется:

Цитата:

В начале 1960-х прерывания стали использовать для имитации одновременного выполнения нескольких программ на одном процессоре.[13] Наличие параллелизма с общей памятью привело к проблеме управления параллелизмом. Первоначально эта задача задумывалась как один из мьютексов на отдельном компьютере. Эдсгер Дейкстра разработал семафоры, а позднее, в период между 1971 и 1973 годах, Чарльз Хоар и Пер Хансен для решения проблемы мьютексов разработали мониторы.[14][15][16] Однако, ни одно из этих решений не создавало в языках программирования конструкций, которые бы инкапсулировали доступ к совместным ресурсам. Инкапсуляцию сделали позже Хьюитт и Аткинсон, построив параллельно-последовательный преобразователь ([Hewitt, Atkinson 1977, 1979] и [Atkinson 1980]).

[AlexDem]

В Хаскеле используется транзакционная память, например.

[nondeterminism]

AlexDem в сообщении #1012671 писал(а):

Вариантов во втором случае меньше, т.е. возможности ограничены по сравнению с первым случаем

Я так и не понял, почему возможности ограничены. Поясните на примере, чтоли.

[AlexDem]

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

[nondeterminism]

AlexDem в сообщении #1012676 писал(а):

В Хаскеле используется транзакционная память, например.

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

[AlexDem]

nondeterminism в сообщении #1012681 писал(а):

Думаю, подобную систему можно и вручную реализовать.

Тогда лучше пересесть на C++. Я ушёл...

[nondeterminism]

AlexDem в сообщении #1012679 писал(а):

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

Да, по поводу производительности -- это само сабой. Я думал, что Вы про выразительные возможности говорите.