>[19] Игорь Шевченко © (2009-01-25 00:21:00)
>Любой "эмулятор динамической типизации" есть безусловное зло.
ППКС.

---
Do what thou wilt shall be the whole of the Law.

>Игорь Шевченко

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

Unknown user ©   (25.01.09 00:42) [21]


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


Э..пример будет ? Типа что "такая-то задача при решении традиционным образом глючит и тормозит а при моем подхоже наичнает безошибочно летать".

Пользователю вообще все равно, сколько там внутре потоков, один или два десятка, главное, чтобы приложение работало в ожидаемых пределах.


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


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

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

Unknown user ©   (24.01.09 22:17)  0

> Так как в сложных системах, при классическом подходе, невозможно
> разделить функциональность между объектами сохранив при
> этом их независимость.

Любая система при любом подходе должна разделять функциональность между объектами, сохраняя их независимость.

>[24] int64 (2009-01-25 11:12:00)
прям таки так? просто таки обязана?

---
All Your Base Are Belong to Us

Ну, да. Именно так. А что тебя удивляет?
Ты первый раз это слышишь? Или не был согласен с этим раньше?
Я больше скажу: "И СЦЕПЛЕНИЕ между объектами обязано быть как можно тоньше".
Вот.
http://en.wikipedia.org/wiki/Coupling_(computer_science)

> [26] int64   (25.01.09 17:27)

Ой... Истина в последней инстанции...
А вы не пророк случаем? :))

Снова встряну. Господам интересующимся, сомневающимся и восхищающимся Actor Model'ю советую посмотреть в сторону Erlang.

> @!!ex ©   (25.01.09 18:06) [27]
> > [26] int64   (25.01.09 17:27)
>
> Ой... Истина в последней инстанции...
> А вы не пророк случаем? :))

Я проповедник.
Проповедовать азбучные истины труднее всего - их сложно доказывать.

> [29] int64   (25.01.09 18:34)

Жаль у нас азбуки от разных языков.
Может все таки стоит понять, что в программировании не бывает истин в последней инстанции.

> Игорь Шевченко ©   (25.01.09 01:33) [22]
> Я извиняюсь еще раз, программисты не создают "мультипоточные
> приложения путем использования потокобезопасных классов",
>  они вполне конкретные задачи решают. Вот на примере чего-
> то конкретного и хотелось бы уяснить преимущества предлагаемой
> модели объектов и сообщений промеж них, причем, диспетчируемых
> через единственное место.

"Диспетчеризация через одно место" :))))

Ладно, если серьёзно, то на Actor Model построен язык Erlang на котором корпорация Эриксон пишет софт для своих телекоммуникационных задач. Язык изначально создавался для реализации высоконадежных систем и очень распараллеленых систем.

Вот тут про него написано в обзорном порядке: http://en.wikipedia.org/wiki/Erlang_(programming_language)

Alkid ©   (25.01.09 20:48) [31]

Я в курсе про Erlang - в смысле, читал про него обзорные статьи.

Речь не о том, у нас сайт вроде про delphi и предложение свое автор (по моему скромному мнению) делает тоже в рамках программирования на Delphi.

Поэтому еще раз - мне бы хотелось уяснить преимущества подхода автора на конкретных примерах на Delphi (не на Erlang, не на APL, не на INTERCAL),
потому как мне кажется одной диспетчеризацией сообщений заместо прямого взаимодействия из Delphi Erlang никак не получить.

> Игорь Шевченко ©   (25.01.09 21:01) [32]

Да, я понимаю. Просто Эрланг представляет собой некую квинтэссенцию идей, часть которых может быть реализована на Дельфи. В частности, когда я реализовывал подобные схемы, получались следующие бонусы:

Сильная изоляция объектов друг от друга. Объекту-источнику сообщения надо было знать минимум или ничего о приемнике (приёмниках) сообщения. Для разных уведомлений, действующих по принципу "выстрелил и забыл" - самое то. Облегчение программирования асинхронной работы (при сохранении возможности синхронного вызова через тот же диспетчер). Повышение уровня изоляции объектов так же снижало воздействие ошибок в одном объекте на другой. Динамическая диспетчеризация вызовов, duck typing. В перспективе планировалось так же на основе этого диспетчера реализовать абстрагирование местоположения объекта, т.е. реализовать распределённость.

Вместе с тем наблюдались и отрицательные стороны такой организации:
1. Большое количество инфраструктурного кода, который приходилось писать руками (вот где шаблонов и метапрограммирования не хватало!)
2. Затрудненность отладки асинхронных и, отчасти, схем взаимодействия.
3. Снижение производительности.

Alkid ©   (25.01.09 22:10) [33]

Я вижу еще одну отрицательную сторону - ослабление контроля за типизацией со стороны компилятора и, как следствие, перенос обнаружения ошибок с времени компиляции на время выполнения.

> Игорь Шевченко ©   (25.01.09 22:27) [34]

Ты знаешь, это вопрос крайне неоднозначный. Есть люди, которые считают статическую типизацию злом и в их аргументах есть своё рациональное зерно. Если интересно: http://www.mindview.net/WebLog/log-0025

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

С одной стороны: чем проще - тем лучше. С другой стороны (особенно, когда пишем движок): чем общнее - тем лучше.

Резюме: на задачу надо смотреть. Поэтому все споры в отрыве от задачи - бессмысленны.

Alkid ©   (25.01.09 22:45) [35]


> Ты знаешь, это вопрос крайне неоднозначный. Есть люди, которые
> считают статическую типизацию злом и в их аргументах есть
> своё рациональное зерно


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

>Alkid

Ваши идеи мне близки по духу. Пока не изобрели кватновые или оптические процессоры, которые будут производительней современных на порядки, остается лишь один способ увеличивать быстродействие. Это распараллеливание выполнения программ. На ближайшие пару десятилетий постепенное увеличение ядер в процессорах будет основной тенденцией. Следовательно надо менять подход в программировании, чтобы использовать новые процессоры на полную мощность.

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

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

Вообще потоки надо воспринимать как ДОПОЛНИТЕЛЬНЫЕ возможности распараллирования естественно там, где оно, это распараллирование, необходимо. Причем тут взаимодействие на уровне визуальных объектов - вообще непонятно.