Здравствуйте, Sinclair, Вы писали:

ВВ>>Это из области "все мы сидим в локалке"? Под локальной сетью обычно имеется в виду все-таки некоторая "сеть", где доступны другие ноды, контент и пр. У меня ADSL2, у меня нет никакой внутренней сети. Причем на самом деле необходимости в ней и не возникает.
ВВ>>Любой мало-мальски приличный торрент, когда разгонится, начинает качать со скоростью более 1Мбайта в сек. Представляем сколько чего можно скачать за ночь. Или за день. Оставив комп включенным.
S>Ну так торрент как раз и использует много поставщиков. С точки зрения провайдера, главное — это его личные расходы на трафик и организацию сети.
S>Тебе хорошо, у тебя толстый канал. В России есть еще места, где такой канал — один на территорию размером с Данию, и его делят все потребители.

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

ВВ>>Я уже высказывал мысль, что скорость каналов должна обогнать рост разрешения видео контента. Потому что последний упирается в пока еще живущие физические носители — тот же блю-рей, который еще и на рынок-то нормально выйти не успел и наверняка проживет довольно долго. А там чего-то сильно отличного от 1960х1080 ты не увидишь, ибо не влезет.
S>А вот я как раз думаю наоборот. Такая ситуация связана с возрастными проблемами среди издателей: они до сих пор мыслят категориями "вот Д.Доу покупает видеокассету, тьфу, то есть диск...". Распространение контента через сеть резко снижает важность конкретного формата, и тем более конкретного носителя.

Снижает. Если мы вообще перейдем на цифровую дистрибьюцию, т.е. физические носители отомрут. Это рано или поздно случится — но пока это не так.

ВВ>>С другой стороны могут конечно перейти от всяких Mp2 на использование других алгоритмов. Ибо я, честно, последнее время в упор не вижу разницы между "аналогом" и каким-нибудь хорошим XVid. Но с другой стороны смысл? Какое разрешение у твоего монитора? А у телевизора? А каково сейчас соотношение SD-телевизоров и HD-телевизоров?
S>Правильно, рост разрешения сейчас по факту сдерживается исключительно возможностями воспроизводящих устройств. Я не в курсе, бывают ли проекторы с более чеем FullHD разрешением. Наращивать разрешение контента на снимающей стороне вполне себе есть куда.

Есть, но смысл это делать, когда нет аппаратуры, к-я позволит оценит все прелести такого высокого разрешения?

ВВ>>Все-таки эта отрасль достаточно инертна, а вот рост интернет-каналов вширь никакие факторы не сдерживают.
S>Вот это мне непонятно. Ты себе вообще представляешь характерные стоимости проводных каналов?
S>Маленький пример: в Северомуйском тоннеле стоимость всего компютерного обрудования пренебрежимо мала по сравнению со стоимостью кабелей, которые к нему подключены.

А тут все просто. Я не говорю, что расширять каналы легко, дешево и пр. Я говорю — что нет сдерживающих факторов, как в случае с ростом разрешений видео. И уже по факту этот рост происходит быстрее, чем, скажем, переход с ДВД на блюрей.

S>Инертность области телевизоров меня, конечно же, угнетает со страшной силой. Потому что я не успеваю прицениться к девайсу, как кто-нибудь выпускает более классный. Вон, Панасоник освоил 42" плазму в FullHD. А LCD вообще без проблем сделать еще в два раза больше — было бы что смотреть.

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

ВВ>>Мне кажется тут будет рулить не технология, которая позволит сэкономить "еще 14%", а та, которая позволит максимально эффективно бороться с пиратством. Ибо благодаря нему потери будут посильнее.
S>Основной способ борьбы с пиратством — отмена сверхприбылей. Сейчас приобретать нелегальный контент удобнее и дешевле, чем легальный.
S>Поэтому как ни борись, а плетью обуха не перешибешь. Достаточно сделать легальный контент удобнее, и пираты отомрут. Грубо говоря, зачем тебе качать камрип из сети, когда ты за $12 в месяц имеешь доступ к нормальному медиа-провайдеру, который отдает тебе FullHD 7.1 с раздельными дорожками для языков? При этом найти нужный фильм, посмотреть связанную с ним информацию и прочее ты можешь прямо там же; сервис подсказывает тебе на основе твоего же опыта, какие фильмы отстой, а какие нет; помимо самого фильма валяется масса материалов типа интервью с командой, текст книги, прочая дополнительная информация. Ну то есть этакая помесь IMDB с Amazon, только круче

Ну знаешь, мне кажется всегда останется актуальной ситуация "этот контент недоступен в вашем регионе".
Я вот, например, люблю смотреть фильмы на русском, ну не нравятся мне без перевода, не потому что не понимаю, просто не нравятся.
А сколько, скажем, интересных сериалов доступно только в каком-нибудь лостфильмовском переводе? Я бы с удовольствием купил бы лицензию, даже несмотря на неудобный по сравнению с HDD носитель, но так нет ее. И я не вижу предпосылок к тому, чтобы эта ситуация поменялась кардинально. Ну будет продавать очередной BSG на английском. А я хочу на русском. Вот тебе и вотчина для пиратов.

ВВ>>Ну если не даваться в детали, то можно, почему нет? Есть же несколько довольно явных тенденций, как мне кажется:
ВВ>>- уход на покой физических носителей, переход на цифровую дистрибьюцию
ВВ>>- объедение различных медиа-устройсв вроде видео-плеера, игровой приставки и пр. в единое развлекательное устройство (что уже почти произошло), через которое будет и телевидение "с кочергой", и видео, и игры. А также музыка и многое другое. Причем это устройство не будут по факту эквивалентно PC и не заменит его.
S>Всё может быть. Проблема с таким устройством — невозможность апгрейда по частям.

Это для пользователя проблема Для производителя даже бенефит. Например, XBox вообще говоря не продается, а дается "на прокат", при этом ты не имеешь права как-либо модифицировать его согласно EULA. Получается даже не XBox, а этакий BlackBox. Зато можно вытворять всякие штуки, вроде автоматического удаления контента с винта. На PC такие вещи будет сложнее замутить.

Здравствуйте, Геннадий Васильев, Вы писали:

ВВ>>Классы не ради ОО-стиля делают, а потому что мыслят саму структуру программы в терминах сущностей, их взаимосвязей и пр. Когда пишут на ОО-языке, то мыслят в ОО-стиле. Разве это не очевидно?
ГВ>Опять двадцать пять. Очевидно только то, что программа проектируется и записывается в ОО-стиле. Это единственное, что может быть очевидно. Остальное — дешёвые домыслы. Спешу дать добрый совет: забудь про выражения, апеллирующие к свойствам субъекта — они изначально неправомерны. И не читай википедию, особенно статью про "парадигму".

К чему написано все вышесказанное? Это возражение на что-то? Что конкретно я домысливал?

ВВ>>А правила по принципу — "давайте все ф-ции делать детерминированными, и тогда у нас получится ФП" — это ни фига ФП, это просто старое хорошое правило декомпизиции функций, к-е еще в СП рулило.
ГВ>Я имел в виду не только детерминированость функций. В детерминированность не очень умещаются, например, функции высших порядков.

Ну вот другие товарищи практически такие функции и считают "чистыми". Хотя ни фига они не чистые в смысле ФП.

ВВ>>Вопрос не в стиле. Вопрос в полной, так сказать, очередной ломке мозгов, необходимость в которой ИМХО назрела. Попробуйте думать не в ОО-ключе. Возможно, вам понравится
ГВ>Блин, это ж как узко надо мыслить, чтобы смена языка программирования превращалась в ломку мозга?!

Речь не о смене языка, а о смене концепции программирования вообще-то.

ГВ>И эти люди... Это ты у Влада нахватался, что ли? Так не учись плохому.

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

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Тем не менее, ОО-языком его можно назвать по критерию наличия явной поддержки хоть какого-то ООП.

Ну в этом твои аргументы схожи с тем же FR. Эти вот ребята тоже считают, что С# можно назвать ФП-языком благодаря "наличию явной поддержки хоть какого-то ФП".
Странный критерий, мне кажется

Здравствуйте, Воронков Василий, Вы писали:


ВВ>А что ты мне пытаешься доказать? Я где-то утверждал, что вин-формс самый лучший ГУИ-фреймворк?
ВВ>Само обсуждение о вин-формсах всплыло как очередное передергивание на тему "никто не защищает веб-формс".
Заметь — передергивание было с твоей стороны. Именно ты привлек в топик ВинФормз.

ВВ>Вин-формы хотя бы построены на основе правильных архитектурных решений. Да, на мой взгляд обработка сообщений через события — это важный момент, и он сделан удачно.
Совершенно неудачно. См. bubbling/sinking как правильный механизм обработки сообщений.
ВВ>Да, "маппинг" окошек на контролы — это хорошо.
Это отвратительно.
ВВ>И это значительно удобнее того, что было в MFC.
Ну, если слаще репы ничего не есть, то таки да. Но мы же не с MFC сравниваем винформз, нет?
ВВ>И это не мешает мне спуститься на более низкий уровень, когда это нужно.
ВВ>Веб-формы построены изначально на в корне неверных архитектурных решениях. Хотя бы потому что они точно такие же, как в вин-формс И сама эта идея — неправильная. Более того, если даже сравнивать отдельные решения, использованные в веб-формс и вин-формс, то веб-формс пожалуй даже выиграет по сумме очков — вот только к чему это все, когда фундамент гнилой?
ВВ>Ты с этим не согласен?
Я согласен. Только вот у веб-форм фундамент как раз хороший; гнилая там — только малозначительная надстройка. Ее можно безболезненно заменить, и построить на том же фундаменте совершенно другое решение.

А в винФормах гнил сам фундамент; поэтому невозможно как-то починить этот фреймворк. Только выкинуть целиком — и тогда получится WPF.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Блин, это ж как узко надо мыслить, чтобы смена языка программирования превращалась в ломку мозга?!

Вполне, если это в первый раз. Тем профильное образование и ценно, что первый раз происходит еще в ВУЗе.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>>>Классы не ради ОО-стиля делают, а потому что мыслят саму структуру программы в терминах сущностей, их взаимосвязей и пр. Когда пишут на ОО-языке, то мыслят в ОО-стиле. Разве это не очевидно?
ГВ>>Опять двадцать пять. Очевидно только то, что программа проектируется и записывается в ОО-стиле. Это единственное, что может быть очевидно. Остальное — дешёвые домыслы. Спешу дать добрый совет: забудь про выражения, апеллирующие к свойствам субъекта — они изначально неправомерны. И не читай википедию, особенно статью про "парадигму".

ВВ>К чему написано все вышесказанное? Это возражение на что-то? Что конкретно я домысливал?

Всё, что касается особеностей мышления собеседника изначально неправомерно.

В терминах ОО-языка можно записать массу всяческих мыслей. В терминах функционального языка — тоже. Язык — это только язык, он влияет до какой-то степени на выбор абстракций, но только до какой-то. Хм. По-моему, я уже где-то об этом говорил, совсем недавно.

ВВ>>>А правила по принципу — "давайте все ф-ции делать детерминированными, и тогда у нас получится ФП" — это ни фига ФП, это просто старое хорошое правило декомпизиции функций, к-е еще в СП рулило.
ГВ>>Я имел в виду не только детерминированость функций. В детерминированность не очень умещаются, например, функции высших порядков.
ВВ>Ну вот другие товарищи практически такие функции и считают "чистыми". Хотя ни фига они не чистые в смысле ФП.

Что-то у тебя всё перепутано. Хоть по словам оспаривай, ёлки зелёные. С одной стороны, я что-то не припомню, чтобы кто-то сводил FP-стиль к детерминированным функциям, а с другой — детерминированные функции вполне себе годятся на "pure FP".

ВВ>>>Вопрос не в стиле. Вопрос в полной, так сказать, очередной ломке мозгов, необходимость в которой ИМХО назрела. Попробуйте думать не в ОО-ключе. Возможно, вам понравится
ГВ>>Блин, это ж как узко надо мыслить, чтобы смена языка программирования превращалась в ломку мозга?!
ВВ>Речь не о смене языка, а о смене концепции программирования вообще-то.

Только не парадигма! Только не парадигма!

Здравствуйте, Воронков Василий, Вы писали:

ГВ>>Тем не менее, ОО-языком его можно назвать по критерию наличия явной поддержки хоть какого-то ООП.
ВВ>Ну в этом твои аргументы схожи с тем же FR. Эти вот ребята тоже считают, что С# можно назвать ФП-языком благодаря "наличию явной поддержки хоть какого-то ФП".
ВВ>Странный критерий, мне кажется

А где это FR называл C# именно функциональным языком?

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Всё, что касается особеностей мышления собеседника изначально неправомерно.
ГВ>В терминах ОО-языка можно записать массу всяческих мыслей. В терминах функционального языка — тоже. Язык — это только язык, он влияет до какой-то степени на выбор абстракций, но только до какой-то. Хм. По-моему, я уже где-то об этом говорил, совсем недавно.

Для этого надо сначала признать, что именно есть эти самые "термины ФП", и они также отличны от того, что было раньше, как ООП от СП.

ГВ>Что-то у тебя всё перепутано. Хоть по словам оспаривай, ёлки зелёные. С одной стороны, я что-то не припомню, чтобы кто-то сводил FP-стиль к детерминированным функциям, а с другой — детерминированные функции вполне себе годятся на "pure FP".

Забавная ситуация получается. С одной стороны "мы это все уже проходили" и "нас ничем не удивить", а уж какой-нибудь там "ломке мозгов" и говорить даже не приходится — типа это все по неопытности и незнанию. С другой стороны — налицо какое-то явное непонимание ФП, раз рождаются такие заявления о детерминированных ф-циях.
ФП не в детерминированность ф-ций упирается, а в иной подход к созданию абстракций. Именно поэтому гибридные языки, пытающиеся соединить в себе "the best of two worlds" и вызывают у меня некоторые сомнения.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Мы вообще о контролах говорим? Или как? Я с таким явлением как способ расширения функционала контролов "вообще" не знаком. И что такое расширение?
ВВ>Чтобы "расширить" DataGridView — я напишу собственный тип ячейки/колонки.

Ага, только колонки и можно расширять, и то весьма примитивно. А что если я захочу: группировку строк; строку с суммой/средним по строкам; объединённые ячейчки, грид, вложенный в ячейку; сложные заголовки? Всё это делается методом выкидывания DataGridView.

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

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ну вот другие товарищи практически такие функции и считают "чистыми". Хотя ни фига они не чистые в смысле ФП.

Они чистые в смысле ФП.
Они полностью удовлетворяют определению чистоты например из "Функционального программирования" Харрисона-Филда.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ну в этом твои аргументы схожи с тем же FR. Эти вот ребята тоже считают, что С# можно назвать ФП-языком благодаря "наличию явной поддержки хоть какого-то ФП".
ВВ>Странный критерий, мне кажется

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

Здравствуйте, FR, Вы писали:

FR>Они чистые в смысле ФП.
FR>Они полностью удовлетворяют определению чистоты например из "Функционального программирования" Харрисона-Филда.

Что, любая детерминированная ф-ция удовлетворяет определению чистоты?

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Забавная ситуация получается. С одной стороны "мы это все уже проходили" и "нас ничем не удивить", а уж какой-нибудь там "ломке мозгов" и говорить даже не приходится — типа это все по неопытности и незнанию. С другой стороны — налицо какое-то явное непонимание ФП, раз рождаются такие заявления о детерминированных ф-циях.

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

ВВ>ФП не в детерминированность ф-ций упирается, а в иной подход к созданию абстракций. Именно поэтому гибридные языки, пытающиеся соединить в себе "the best of two worlds" и вызывают у меня некоторые сомнения.

То есть такие языки как Ocaml, F#, ML, Scheme, Nemerle, Scala сомнительны?

Здравствуйте, Воронков Василий, Вы писали:

FR>>Они чистые в смысле ФП.
FR>>Они полностью удовлетворяют определению чистоты например из "Функционального программирования" Харрисона-Филда.

ВВ>Что, любая детерминированная ф-ция удовлетворяет определению чистоты?

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

Здравствуйте, FR, Вы писали:

ВВ>>Забавная ситуация получается. С одной стороны "мы это все уже проходили" и "нас ничем не удивить", а уж какой-нибудь там "ломке мозгов" и говорить даже не приходится — типа это все по неопытности и незнанию. С другой стороны — налицо какое-то явное непонимание ФП, раз рождаются такие заявления о детерминированных ф-циях.
FR>Это у зомбированных немерле свое понимание, из которого выходит что если управляющие конструкции устроены иначе чем в немерле то такой язык не пригоден для ФП. Я же просто показал что для для программирования в ФП стиле нужна совсем малость.

Тогда проясни в чем отличия программирования в ФП стиле и собственно ФП-программирования.

ВВ>>ФП не в детерминированность ф-ций упирается, а в иной подход к созданию абстракций. Именно поэтому гибридные языки, пытающиеся соединить в себе "the best of two worlds" и вызывают у меня некоторые сомнения.
FR>То есть такие языки как Ocaml, F#, ML, Scheme, Nemerle, Scala сомнительны?

Соединение ООП и ФП лично у меня — да, вызывает некоторое сомнение в том, что это правильный путь. И в первую очередь мне на ум приходит тот же самый немерле.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Тогда проясни в чем отличия программирования в ФП стиле и собственно ФП-программирования.

Программирование в ФП стиле это программирование с использованием функциональной декомпозиции, с использованием преимуществ которые дают чистота и прозрачность по ссылкам и ФВП. Многое из этого можно применить даже в C++, еще больше в шарпе, питоне или D.

ВВ>>>ФП не в детерминированность ф-ций упирается, а в иной подход к созданию абстракций. Именно поэтому гибридные языки, пытающиеся соединить в себе "the best of two worlds" и вызывают у меня некоторые сомнения.
FR>>То есть такие языки как Ocaml, F#, ML, Scheme, Nemerle, Scala сомнительны?

ВВ>Соединение ООП и ФП лично у меня — да, вызывает некоторое сомнение в том, что это правильный путь. И в первую очередь мне на ум приходит тот же самый немерле.

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

Здравствуйте, Sinclair, Вы писали:

ВВ>>А что ты мне пытаешься доказать? Я где-то утверждал, что вин-формс самый лучший ГУИ-фреймворк?
ВВ>>Само обсуждение о вин-формсах всплыло как очередное передергивание на тему "никто не защищает веб-формс".
S>Заметь — передергивание было с твоей стороны. Именно ты привлек в топик ВинФормз.

Ты знаешь — случайно упомянул. Ей-богу, уже страшно писать что-то — чуть что, сразу начинается какой-то флейм. Этак можно выцепить любую фразу — и понеслась.

ВВ>>Вин-формы хотя бы построены на основе правильных архитектурных решений. Да, на мой взгляд обработка сообщений через события — это важный момент, и он сделан удачно.
S>Совершенно неудачно. См. bubbling/sinking как правильный механизм обработки сообщений.
ВВ>>Да, "маппинг" окошек на контролы — это хорошо.
S>Это отвратительно.

Обосновать можешь? В контексте именно ГУИ-фреймворка.

ВВ>>И это значительно удобнее того, что было в MFC.
S>Ну, если слаще репы ничего не есть, то таки да. Но мы же не с MFC сравниваем винформз, нет?

"Мы" — это кто? Я сравниваю именно с МФС вообще-то. В мире вин32 вин-формс были неплохим таким шагом вперед. По-моему странно обсуждать это. И странно критиковать их сейчас, когда собственно то, над чем они строятся уходит на покой.
Я же для веб-формс не искал каких-то особенно "крутых" соперников. Меня устраивало любое сравнение. Хотите ПХП, хотите АСП. Я вот не знаю SWT или wxWidgets. Ну и как мне реагировать на всякие "вот в wxWidgets это сделано лучше". Да ради бога, может и лучше.
Собственно, если бы даже вин-формс были самым неудачным ГУИ-фреймворков (что абсолютно неправда на самом деле), это как бы не исключало того факта, что архитектурно они более правильны чем веб-формс.

ВВ>>И это не мешает мне спуститься на более низкий уровень, когда это нужно.
ВВ>>Веб-формы построены изначально на в корне неверных архитектурных решениях. Хотя бы потому что они точно такие же, как в вин-формс И сама эта идея — неправильная. Более того, если даже сравнивать отдельные решения, использованные в веб-формс и вин-формс, то веб-формс пожалуй даже выиграет по сумме очков — вот только к чему это все, когда фундамент гнилой?
ВВ>>Ты с этим не согласен?
S>Я согласен. Только вот у веб-форм фундамент как раз хороший; гнилая там — только малозначительная надстройка. Ее можно безболезненно заменить, и построить на том же фундаменте совершенно другое решение.

А какой фундамент у веб-форм? Может, еще к архитектуре ИИС обратимся, и ее в плюсы веб-форм запишем? Всякие хендлеры — это практически тривиальная обвертка над ИЗАПИ, не более.
Потом это опять спор о терминах. Фундамент, не фундамент. Есть концепция заложенная в веб-форм. Та же обработка пост-бека через события. Это одна из основных концепций программирования на веб-формс. Эта концепция неудачная. Аналогичная концепция в вин-формс куда более удачно ложится на "предметную область". Вот, собственно, и все.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>А о чем тогда спор?
S>Ну, раньше был о производительности и методах ее достижения.
S>Ты с какой-то непонятной мне целью свернул его на UI-фреймворки.

Ну первым страшное слово АСП.НЕТ сказал ты. Точно также как и я первым сказал страшное слово ВинФормс. Так что виноват в этом флейме ты

ВВ>>А на WTL смысл есть смотреть?
S>Нет, нету.
ВВ>>Каким образом тут Хром всплыл, мне интересно?
S>У тебя трудности с памятью или с восприятием? Цитирую место, где всплыл хром:
S>

S>Единственный способ написать удачное GUI приложение — это захватить одно окно (в терминах user32), а внутри него выполнять отрисовку вручную. То есть, конечно же, не вручную, а при помощи некоторого совершенно другого фреймворка, у которого базовые примитивы устроены вовсе не так, как предлагают user32 и comctl32.
S>В качестве недавних примеров таких приложений можно посмотреть на Chrome.

S>Что тут непонятно? Что у хрома всего два user32-окна? Ну так запусти Spy++ и посмотри.

Да знаешь, на вид там вообще одно окно
Хром вообще такое типичное WTL-ное приложение, они там даже какие-то фишки узают, которые еще в репозитории только доступны.

ВВ>>А можно по-конкретнее? Что там неудобно? Что сложно реализовать?
S>Любая анимация состояния — это pain.

Это в юзер32 всегда так.

S>Любые игры с выходом за пределы своего clip rect типа теней, обводки, и прочих glow — pain.

Опять-таки ограничение окошек.

S>Масштабирование — pain.

И опять-таки. Чтобы обойти все это, надо фактически не использовать "окошки". Но какая же это тогда надстройка над окошками, а?

S>Композитные контролы — тройной pain.

А тут-то в чем проблема?

S>Cкорее возникает вопрос — а что там реализовать легко и удобно.

Все, что нормально ложится на юзер32 + кое-что еще.
Вот рисование через примитивы ГДИ+ вполне себе легко и удобно, например.

S>Практика показывает, что легко и удобно делать только примеры для книжек "как не должен быть устроен UI".

Может быть "не" стоит убрать? Вин-интерфейс вообще-то должен отвечать определенным стандартам, быть *шаблонным* (за исключение редких программ). Сама вин сделана на "окошках". Так что для "шаблонного" вин UI там всего достаточно.

S>Более-менее нормальные решения делать уже сложно. Для хороших, повторюсь, нужно выкидывать весь стандартный стек и брать свой.
ВВ>>Реализация одного и того же функционала — допустим контрол, с большим кол-вом owner draw — на GDI+ и на WPF занимает почему-то весьма и весьма схожее время. Реализация этого функционала на WPF получается никак не "проще". При этом еще и АА в итоге кривой
S>Мы с WPF играли мало, но наши эксперименты показывают ровно обратную ситуацию. Большое количество Owner Draw в жизненных примерах достигается не выпиливанием по пикселам, а выбором правильных векторных примитивов. К тому же их рисует дизайнер, у которого рука набита, а не программист.

Что за "выпиливание по пикселям"? В ГДИ+ вполне удобные примитивы, не припомню, чтобы я там что-то "выпиливал".
Попробуйте нарисовать какой-нибудь нетривиальный контрол — например, показывающий температуру в виде градусника. Или там скорость ветра в виде спидометра. Вот недавно такую хрень рисовали как раз.
На WPF — по трудозатрам — ну практически те же яйца.

ВВ>>Вообще-то я игрался с HTMLayout, правда не очень недавно. И он именно, что HTML и рендерит Причем на тот момент не дружил с XHTML и CSS.
S>То, что он рендерит — это не HTML. Это его близкий родственник, конечно, но это язык разметки UI, а не гипертекста. Вон посмотри на терраинформатике примеры приложений, UI которых построен на HTMLayout.

Ради бога. Но мне показалось, что это очень похоже на ХТМЛ

ВВ>>"Все", значит, считают, что ASP.NET "нигде не кончается", т.е. практически эквивалентент понятию .NET,
S>Главное — это то, что все считают, что ASP.NET не сводится к System.Web.UI.Page.

А мне интересно обсудить именно System.Web.UI.Page и все с ним сопряженное. А не то, к чему он там сводится или не сводится.

Здравствуйте, FR, Вы писали:

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

Ну, собственно, даже бескомпромиссный Хаскель вполне себе ОО.

Здравствуйте, Воронков Василий, Вы писали:

S>>Совершенно неудачно. См. bubbling/sinking как правильный механизм обработки сообщений.
ВВ>>>Да, "маппинг" окошек на контролы — это хорошо.
S>>Это отвратительно.
ВВ>Обосновать можешь? В контексте именно ГУИ-фреймворка.
Конечно могу. Пример на пальцах: делаем композитный контрол. В идеологии окошко=контрол он обязан иметь оконный хендл, а все его компоненты обязаны быть его дочерними окнами. Что абсолютно никак не требуется по логике самого контрола — ни рисование, ни event processing не пострадают, если запчасти от контрола будут разнесены. А я, может быть, хочу линию вертикальную нарисовать между label и input. Упс, только наследоваться и сабкласситься.

ВВ>"Мы" — это кто? Я сравниваю именно с МФС вообще-то.
Вопрос — зачем? Берем говно, сравниваем с ним другое говно. Поверь, никому это не интересно.
ВВ>В мире вин32 вин-формс были неплохим таким шагом вперед. По-моему странно обсуждать это. И странно критиковать их сейчас, когда собственно то, над чем они строятся уходит на покой.
ВВ>Я же для веб-формс не искал каких-то особенно "крутых" соперников. Меня устраивало любое сравнение. Хотите ПХП, хотите АСП.


ВВ>Я вот не знаю SWT или wxWidgets. Ну и как мне реагировать на всякие "вот в wxWidgets это сделано лучше".
Как на повод повысить свою квалификацию. . Если тебе неинтересен вопрос "как должен быть устроен хороший GUI-framework", то не надо было поднимать эту тему в этом форуме. Если интересен — забей на устаревший отстой; смотри на лучшие достижения.

ВВ>Да ради бога, может и лучше.
ВВ>Собственно, если бы даже вин-формс были самым неудачным ГУИ-фреймворков (что абсолютно неправда на самом деле), это как бы не исключало того факта, что архитектурно они более правильны чем веб-формс.
Знаешь, мне трудно сравнивать два отстоя на предмет большей или меньшей правильности. Их надо не сравнивать, а выкидывать на помойку.

S>>Я согласен. Только вот у веб-форм фундамент как раз хороший; гнилая там — только малозначительная надстройка. Ее можно безболезненно заменить, и построить на том же фундаменте совершенно другое решение.

ВВ>А какой фундамент у веб-форм?
И в четвертый раз разжевываю: IHttpHandler/IHttpModule/BuildProvider. Вот основной фундамент.
Дальше мы увидим еще N провайдеров, которые можно считать фундаментом, а можно — подвалом. Всё это сделано очень хорошо.
ВВ>Может, еще к архитектуре ИИС обратимся, и ее в плюсы веб-форм запишем? Всякие хендлеры — это практически тривиальная обвертка над ИЗАПИ, не более.
Тривиальная? Ну-ну. Я бы вот так с налёту не смог написать аналог инфраструктуры ASP.NET. Ты вообще смотрел на классы ISAPI*? Или так, понты колотишь?

ВВ>Потом это опять спор о терминах. Фундамент, не фундамент. Есть концепция заложенная в веб-форм. Та же обработка пост-бека через события. Это одна из основных концепций программирования на веб-формс.
ВВ>Эта концепция неудачная.
С этим никто не спорит. Точка. По-прежнему продолжаю не понимать, зачем заниматься копрофагией.

ВВ>Аналогичная концепция в вин-формс куда более удачно ложится на "предметную область".
Ты имел в виду наоборот — "на нижележащую технологию", надо полагать? Потому как на предметную область это ложится плохо. Простейший пример из предметной области: делаем композитный контрол с большим количеством child controls. Из-за отсутствия bubbling, композитный контрол вынужден заниматься ретрансляцией событий от детей путем подписывания на события каждого из них. Никак не могу назвать эту концепцию удачной — язык не поворачивается.
ВВ>Вот, собственно, и все.