Ответ на »сообщение 5253« (Jack Of Shadows)
___________________________

И куда же ? У вас есть идея ?

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

Ответ на »сообщение 5252« (Jack Of Shadows)
___________________________

Не понял, поясните. Вы имеете в виду отдельные sql stetaments или служебные слова from,  where, group by внутри одного sql statement ?
Если первое, то для изменения состояния (insert, update, delete) важно. ТАКЖЕ как и в хаскеле :))

Поскольку SQL общественное мнение причисляет к декларативным языкам, то последовательность выполнения операторов (синхрон в потоке управления) как-то вроде перестает быть неотъемлемой частью ИП.

Они совершенно не должны это делать синхронно и последовательно. Какое это имеет отношение к ООП или обсуждению имеративное/функциональное программирование ?

Это имеет отношении к классификации языков и парадигм. Мэйнстрим-ООП и ООП вообще -- разные вещи. Из той схемы, что я вкратце обрисовал, вроде как ООП нельзя отнести к императивному программированию. Хотя опять-таки, а что это за штука, ИП? Мои поиски найти более-менее четкий и авторитетный ответ на этот вопрос пока ничем не увенчались. Каждый понимает по-своему. Тогда, пардон, какая польза от такого деления?

Но вот опять ветку по оберону захватили функциональщики :))
Сообщения с номера № 5242 наверное будет лучше перенести на ветку ФП.
Оберонистам я думаю совсем не интересно захламлять свою ветку тем что к их языку никакого отношения не имеет.

Ответ на »сообщение 5251« (Руслан Богатырев)
___________________________
Быть может, не надо этим ограничиваться, а двигаться смелее, еще дальше? :)

И куда же ? У вас есть идея ?

Ответ на »сообщение 5250« (Руслан Богатырев)
___________________________
Важна ли в SQL последовательность операторов?


Не понял, поясните. Вы имеете в виду отдельные sql stetaments или служебные слова from,  where, group by внутри одного sql statement ?
Если первое, то для изменения состояния (insert, update, delete) важно. ТАКЖЕ как и в хаскеле :))

Smalltalk... Почему они должны это делать синхронно и последовательно?
Они совершенно не должны это делать синхронно и последовательно. Какое это имеет отношение к ООП или обсуждению имеративное/функциональное программирование ?

Такое асинхронное ООП перестанет быть ООП?

Нет не перестанет. И именно поэтому у вас ни черта не получится с асинхронным ООП :)) Гарантий то нет.
Если только вы не запретите присваивание конечно. Однако в этом случае вы получите... Erlang :))

Ответ на »сообщение 5249« (Jack Of Shadows)
___________________________

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

Быть может, не надо этим ограничиваться, а двигаться смелее, еще дальше? :)

Ответ на »сообщение 5249« (Jack Of Shadows)
___________________________

Нет. Императивность -это КАК. Декларативность это ЧТО.
Вы не обьясняете sql серверу КАК найти данные которые вы хотите посмотреть/изменить/удалить. Вы говорите ему ЧТО найти. А вот КАК он это будет делать уже скрыто от вас.

Важна ли в SQL последовательность операторов?


Далее: ОО - это ведь тоже попытка обуздать, ограничить глобальное состояние областью видимости классов. Хреновая попытка, половинчатая, но все же - работающая, практичная, для своего времени прогрессивная.

Представим себе ООП близкое к классическому Smalltalk. Есть отправка сообщений объектам (классам), которые и осуществляют реакцию на эти сообщения (путем "коммутации" сообщения с неким кодом, возможно динамической и зависящей от контекста). Почему они должны это делать синхронно и последовательно? Такое асинхронное ООП перестанет быть ООП?

Ответ на »сообщение 5245« (Руслан Богатырев)
___________________________
Представим себе, что в языке (Occam -- это так, для понимания вариантов) нет глобального состояния

А вот в хаскеле есть глобальное состояние, как в паскале. И что ? хаскель и паскаль одного поля ягоды ? Более того в хаскеле тоже можно менять состояние (иначе его невозможно было бы просто использовать) Разве это делает хаскель императивным ?

Далее: ОО - это ведь тоже попытка обуздать, ограничить глобальное состояние областью видимости классов. Хреновая попытка, половинчатая, но все же - работающая, практичная, для своего времени прогрессивная.

Область видимости состояния (глобальное или локальное) особенное значение с точки зрения оранизации вычислений не имеет.
Многолетний опыт ОО показывает, что как ни пытайся убрать состояние внурть обьектов, сделать его локальным, все равно сложность задачи не удается удержать от взрывного роста.
Да, какой то ЗНАЧИТЕЛЬНЫЙ выигрыш по сравнению с процедурным программирование это дает. Но до определенного предела. О потолке абстракции мы уже говорили на ветке ФП.

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

Кстати, а SQL -- императивный язык?
Нет. Императивность -это КАК. Декларативность это ЧТО.
Вы не обьясняете sql серверу КАК найти данные которые вы хотите посмотреть/изменить/удалить. Вы говорите ему ЧТО найти. А вот КАК он это будет делать уже скрыто от вас.

Ответ на »сообщение 5244« (Сергей Перовский)
___________________________

В функциональном программировании присваивание невозможно в силу отсутствия понятия состояния.

Я так понял, что между неимперативным программированием и функциональным ставится знак тождества. Но ведь есть, как минимум, декларативное программирование, противопоставляемое обычно императивному. И ФП не исчерпывает это множество.

Ответ на »сообщение 5243« (Jack Of Shadows)
___________________________

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

Простой вопрос: Вы знаете, КТО пишет ту или иную словарную статью? Какова ДОСТОВЕРНОСТЬ информации? Кто занимается ее редакторским контролем?