Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 5256 26-09-2007 18:51 | |
Ответ на »сообщение 5253« (Jack Of Shadows)
___________________________
И куда же ? У вас есть идея ?
Идеи есть, и лежат они в сфере асинхрона. Что-то подсказывает, что разумное сочетание того и другого (синхрона в малом и асинхрона в большом) да еще с ортогональным базисом языков может дать некий ключик к контролю сложности и эффективному использованию параллельных архитектур.
№ 5255 26-09-2007 18:48 | |
Ответ на »сообщение 5252« (Jack Of Shadows)
___________________________
Не понял, поясните. Вы имеете в виду отдельные sql stetaments или служебные слова from, where, group by внутри одного sql statement ?
Если первое, то для изменения состояния (insert, update, delete) важно. ТАКЖЕ как и в хаскеле :))
Поскольку SQL общественное мнение причисляет к декларативным языкам, то последовательность выполнения операторов (синхрон в потоке управления) как-то вроде перестает быть неотъемлемой частью ИП.
Они совершенно не должны это делать синхронно и последовательно. Какое это имеет отношение к ООП или обсуждению имеративное/функциональное программирование ?
Это имеет отношении к классификации языков и парадигм. Мэйнстрим-ООП и ООП вообще -- разные вещи. Из той схемы, что я вкратце обрисовал, вроде как ООП нельзя отнести к императивному программированию. Хотя опять-таки, а что это за штука, ИП? Мои поиски найти более-менее четкий и авторитетный ответ на этот вопрос пока ничем не увенчались. Каждый понимает по-своему. Тогда, пардон, какая польза от такого деления?
№ 5254 26-09-2007 18:42 | |
Но вот опять ветку по оберону захватили функциональщики :))
Сообщения с номера № 5242 наверное будет лучше перенести на ветку ФП.
Оберонистам я думаю совсем не интересно захламлять свою ветку тем что к их языку никакого отношения не имеет.
№ 5253 26-09-2007 18:38 | |
Ответ на »сообщение 5251« (Руслан Богатырев)
___________________________
Быть может, не надо этим ограничиваться, а двигаться смелее, еще дальше? :)
И куда же ? У вас есть идея ?
№ 5252 26-09-2007 18:32 | |
Ответ на »сообщение 5250« (Руслан Богатырев)
___________________________
Важна ли в SQL последовательность операторов?
Не понял, поясните. Вы имеете в виду отдельные sql stetaments или служебные слова from, where, group by внутри одного sql statement ?
Если первое, то для изменения состояния (insert, update, delete) важно. ТАКЖЕ как и в хаскеле :))
Smalltalk... Почему они должны это делать синхронно и последовательно?
Они совершенно не должны это делать синхронно и последовательно. Какое это имеет отношение к ООП или обсуждению имеративное/функциональное программирование ?
Такое асинхронное ООП перестанет быть ООП?
Нет не перестанет. И именно поэтому у вас ни черта не получится с асинхронным ООП :)) Гарантий то нет.
Если только вы не запретите присваивание конечно. Однако в этом случае вы получите... Erlang :))
№ 5251 26-09-2007 18:32 | |
Ответ на »сообщение 5249« (Jack Of Shadows)
___________________________
После пробуксовки ОО, следущий логический шаг в борьбе со сложностью больших задач - это выделение состояния в отдельные островки. Именно то направление в котором движется современное ФП (хаскель)
Быть может, не надо этим ограничиваться, а двигаться смелее, еще дальше? :)
№ 5250 26-09-2007 18:21 | |
Ответ на »сообщение 5249« (Jack Of Shadows)
___________________________
Нет. Императивность -это КАК. Декларативность это ЧТО.
Вы не обьясняете sql серверу КАК найти данные которые вы хотите посмотреть/изменить/удалить. Вы говорите ему ЧТО найти. А вот КАК он это будет делать уже скрыто от вас.
Важна ли в SQL последовательность операторов?
Далее: ОО - это ведь тоже попытка обуздать, ограничить глобальное состояние областью видимости классов. Хреновая попытка, половинчатая, но все же - работающая, практичная, для своего времени прогрессивная.
Представим себе ООП близкое к классическому Smalltalk. Есть отправка сообщений объектам (классам), которые и осуществляют реакцию на эти сообщения (путем "коммутации" сообщения с неким кодом, возможно динамической и зависящей от контекста). Почему они должны это делать синхронно и последовательно? Такое асинхронное ООП перестанет быть ООП?
№ 5249 26-09-2007 18:12 | |
Ответ на »сообщение 5245« (Руслан Богатырев)
___________________________
Представим себе, что в языке (Occam -- это так, для понимания вариантов) нет глобального состояния
А вот в хаскеле есть глобальное состояние, как в паскале. И что ? хаскель и паскаль одного поля ягоды ? Более того в хаскеле тоже можно менять состояние (иначе его невозможно было бы просто использовать) Разве это делает хаскель императивным ?
Далее: ОО - это ведь тоже попытка обуздать, ограничить глобальное состояние областью видимости классов. Хреновая попытка, половинчатая, но все же - работающая, практичная, для своего времени прогрессивная.
Область видимости состояния (глобальное или локальное) особенное значение с точки зрения оранизации вычислений не имеет.
Многолетний опыт ОО показывает, что как ни пытайся убрать состояние внурть обьектов, сделать его локальным, все равно сложность задачи не удается удержать от взрывного роста.
Да, какой то ЗНАЧИТЕЛЬНЫЙ выигрыш по сравнению с процедурным программирование это дает. Но до определенного предела. О потолке абстракции мы уже говорили на ветке ФП.
После пробуксовки ОО, следущий логический шаг в борьбе со сложностью больших задач - это выделение состояния в отдельные островки. Именно то направление в котором движется современное ФП (хаскель)
Кстати, а SQL -- императивный язык?
Нет. Императивность -это КАК. Декларативность это ЧТО.
Вы не обьясняете sql серверу КАК найти данные которые вы хотите посмотреть/изменить/удалить. Вы говорите ему ЧТО найти. А вот КАК он это будет делать уже скрыто от вас.
№ 5248 26-09-2007 18:03 | |
Ответ на »сообщение 5244« (Сергей Перовский)
___________________________
В функциональном программировании присваивание невозможно в силу отсутствия понятия состояния.
Я так понял, что между неимперативным программированием и функциональным ставится знак тождества. Но ведь есть, как минимум, декларативное программирование, противопоставляемое обычно императивному. И ФП не исчерпывает это множество.
№ 5247 26-09-2007 17:58 | |
Ответ на »сообщение 5243« (Jack Of Shadows)
___________________________
Я отношусь к википедии гораздо большим доверием и уважением нежели вы. Впрочем это уже личный выбор каждого.
Простой вопрос: Вы знаете, КТО пишет ту или иную словарную статью? Какова ДОСТОВЕРНОСТЬ информации? Кто занимается ее редакторским контролем?
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|