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

AVK>>Убогий дизайн.
ВВ>Где именно?
Везде. Скажем, так и не появилось нормальных систем layout'ов, хотя бы как в SWING'е в Java.

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

AVK>>>Убогий дизайн.
ВВ>>Где именно?
C>Везде. Скажем, так и не появилось нормальных систем layout'ов, хотя бы как в SWING'е в Java.

TableLayoutPanel, FlowLayoutPanel — совсем ненормальные? Причем и то и другое в любом случае реализуется самостоятельно, в качестве контрола.

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

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

ВВ>Может объяснишь в чем принципиальное отличие?

Чего от чего? HTML от XAML? Такое же, как HTML от SOAP, к примеру. XAML сам по себе никакой семантики не содержит, это просто формат сериализации графа компонентов в терминах специальной компонентной модели. HTML же подразумевает вполне конкретную сематику и абсолютно нерасширяем.

ВВ>>>Только вот в итоге все равно непонятно, что в вин-формс не нравится. Уровень абстракции недостаточно высок?
AVK>>Убогий дизайн.

ВВ>Где именно?

А ты сам не видишь? Во-первых, практически единственный способ расширения функционала контролов — наследование. Почему плохо наследование реализации здесь уже обсуждалось не раз. Кроме того, использование наследования для расширения функционала это нарушение LSP. Использование же, скажем, агрегации практически невозможно ввиду того самого дизайна и подвязки на виндовый хендл.
Во-вторых, взгляни на публичный контракт Control. Он имеет огромный размер и содержит большое количество грубейших нарушений SRP. В WPF он в разы меньше, хотя и там в этом плане косяков предостаточно.
В-третьих, крайне убогие средства реюза готовых кусков UI. UserControl это все, что на эту тебу имеется. Даже нелюбимые тобой вебформсы в этом плане куда богаче.
В-четвертых, убогий, запутанный и крайне плохо расширяемый механизм баиндинга данных.
В-пятых, крайне примитивная компонентная модель, которую правда, в отличие от, по месту подкрутить все таки можно.
В-шестых, большинство контролов имеют неудобный и примитивный API для взаимодействия с состоянием. Виртуальный режим кое где со скрипом появился, но почти всегда с кривизной.
Ну и куча всего по мелочи.
Итого, дизайн винформсов весьма неоднородный и, в среднем, находится на уровне начала 90-х.

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

C> Скажем, так и не появилось нормальных систем layout'ов, хотя бы как в SWING'е в Java.

Это уже большей частью не дизайн, это реализация.

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

ВВ>>>Где именно?
C>>Везде. Скажем, так и не появилось нормальных систем layout'ов, хотя бы как в SWING'е в Java.
ВВ>TableLayoutPanel, FlowLayoutPanel — совсем ненормальные? Причем и то и другое в любом случае реализуется самостоятельно, в качестве контрола.
Нет, не нормальные. Они появились, AFAIR, далеко не в первой версии WinForms.

Ещё очень не хватает нормального разделения модель/вид.

ВВ>Мне вот интересно какие есть претензии именно к дизайну, архитектуре вин-формс, с учетом того, что это фреймворк построенный над юзер32. Приводить тут в качестве аргумента какие-то контролы не совсем в кассу мне кажется.
Это не "контролы", а дизайн самой системы. Поверх user32 прекрасно строятся вполне нормальные графические системы. См.: SWT+JFace.

WPF реально сделан более правильно, чем почти все остальные оконные системы.

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

C>> Скажем, так и не появилось нормальных систем layout'ов, хотя бы как в SWING'е в Java.
AVK>Это уже большей частью не дизайн, это реализация.
Как сказать... Благодаря layout'ам большинство не совсем уж криворуких приложений на SWINGе имеют resolution independence и нормальный resize. Это заранее закладывалось в дизайн самого SWINGа. Различие в архитектуре тут, ИМХО, вполне есть.

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

C>Как сказать... Благодаря layout'ам большинство не совсем уж криворуких приложений на SWINGе имеют resolution independence и нормальный resize.

Нормальный ресайз можно обеспечить и сейчас. Что же касается resolution independence, то никаких фундаментальных ограничений к тому дизайн винформсов не вносит. Я бы еще понял, если бы вопросы были к отсутствию сменных единиц измерения размера, но в свинге, емнип, в этом плане ситуация точно такая же.

C> Различие в архитектуре тут, ИМХО, вполне есть.

Я пока что существенных различий в архитектуре не вижу. Даже getX и getY в свинге умудрились вкрячит в базовый JComponent.

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

ВВ>>Может объяснишь в чем принципиальное отличие?
AVK>Чего от чего? HTML от XAML? Такое же, как HTML от SOAP, к примеру. XAML сам по себе никакой семантики не содержит, это просто формат сериализации графа компонентов в терминах специальной компонентной модели. HTML же подразумевает вполне конкретную сематику и абсолютно нерасширяем.

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

ВВ>>>>Только вот в итоге все равно непонятно, что в вин-формс не нравится. Уровень абстракции недостаточно высок?
AVK>>>Убогий дизайн.
ВВ>>Где именно?

AVK>А ты сам не видишь? Во-первых, практически единственный способ расширения функционала контролов — наследование.

Мы вообще о контролах говорим? Или как? Я с таким явлением как способ расширения функционала контролов "вообще" не знаком. И что такое расширение?
Чтобы "расширить" DataGridView — я напишу собственный тип ячейки/колонки.
Для изменения поведения некоторых контролов — например при валидации ошибок — я буду использовать совершенно отдельный такой проперти-провайдер.
Да и еще помнится только взяв в руки вин-формс в году этак 2003 я делал owner-draw меню без всякого наследования, а через отдельный такой класс-адаптер. Глупый тогда был, не знал, что наследоваться надо.
Слушай, а для того, чтобы красивый тултип к контролу добавить — тоже небось наследоваться придется?

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

Как хендл связан с агрегацией, а?

AVK>Во-вторых, взгляни на публичный контракт Control. Он имеет огромный размер и содержит большое количество грубейших нарушений SRP. В WPF он в разы меньше, хотя и там в этом плане косяков предостаточно.
AVK>В-третьих, крайне убогие средства реюза готовых кусков UI. UserControl это все, что на эту тебу имеется. Даже нелюбимые тобой вебформсы в этом плане куда богаче.

Расскажи какие сценарии реюза тебе требовались, и ты не смог их реализовать на вин-формс. Может, вместе сообразим что

AVK>В-четвертых, убогий, запутанный и крайне плохо расширяемый механизм баиндинга данных.
AVK>В-пятых, крайне примитивная компонентная модель, которую правда, в отличие от, по месту подкрутить все таки можно.
AVK>В-шестых, большинство контролов имеют неудобный и примитивный API для взаимодействия с состоянием. Виртуальный режим кое где со скрипом появился, но почти всегда с кривизной.
AVK>Ну и куча всего по мелочи.
AVK>Итого, дизайн винформсов весьма неоднородный и, в среднем, находится на уровне начала 90-х.

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

Да и по поводу "большинство контролов имеют неудобный и примитивный API для взаимодействия с состоянием" — это вы, батенька, зажрались. У меня вот культурный шок был, когда я увидел ту же модель событий в вин-формс. Ибо это было настолько удобнее и *понятнее* того, что было... И как раз в вин-формс она абсолютно к месту.
Сейчас это конечно уже не так воспринимается. Но сам юзер32 архаичен, олё! Вы хотите увидеть модный фреймворк на его основе? Это вряд ли. Но вин-формс это ИМХО лучшая надстройка над юзер32 что есть сейчас.

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

ВВ>Что значит — HTML содержит "вполне конкретную" семантику?

То и значит. Каждый тег имеет вполне конкретное, присущее самому HTML значение. Тег же в XAML несет в себе довольно мало семантики, в основном это увязка с его компонентной моделью, которая неизмеримо более примитивна, нежели HTML. Все остальное навешивает уже конкретный фреймворк, который XAMLом пользуется.

ВВ> Конкретную для кого?

Для всех.

ВВ> Кроме общих слов есть что-нибудь сказать?

Это не общие слова, это вполне себе конкретика.

ВВ>HTML — язык разметки, описывающий структуру страницы, используемые на ней элементы и их визуальное представление.

Ну вот видишь, ты сам все знаешь.

ВВ> XAML делает то же самое абсолютно.

Нет. Ничего этого в XAML нет. Термины XAML это: меппинг пространства имен, компоненты, свойства, присоединенные свойства, контент.

ВВ> Можешь называть это "форматом сериализации" или как-то иначе — суть от этого не изменится.

Суть конечно не изменится, чего бы я не называл. Главное, что эта суть по факту совсем не та суть, что в HTML.

ВВ> Про HTML я тоже могу сказать, что это формат сериализации объектной модели документа, и что?

И все. Даже если это так (а это не так), то это не просто формат сериализации документа, это формат вполне конкретного документа. Ни для чего другого он не годен.

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

Что, никогда не наследовался от контролов винформсов? А если наследовался, не скажешь с какой целью?

ВВ> И что такое расширение?

Словарик руского языка подарить?

ВВ>Чтобы "расширить" DataGridView — я напишу собственный тип ячейки/колонки.

Ага, это единственный контрол, который хоть что то из себя в плане дизайна представляет.

ВВ>Для изменения поведения некоторых контролов — например при валидации ошибок — я буду использовать совершенно отдельный такой проперти-провайдер.

Вот только, скажем, код отработки default button и ее modal result намертво прошит в код Form.

ВВ>Да и еще помнится только взяв в руки вин-формс в году этак 2003 я делал owner-draw меню без всякого наследования, а через отдельный такой класс-адаптер.

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

ВВ>Слушай, а для того, чтобы красивый тултип к контролу добавить — тоже небось наследоваться придется?

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

ВВ>Как хендл связан с агрегацией, а?

А ты попробуй отнаследовать свой контрол от Control и агрегировать в нем функционал, скажем, TreeView.

ВВ>Расскажи какие сценарии реюза тебе требовались, и ты не смог их реализовать на вин-формс.

Например когда шаблон UI не квадратный кусок, а состоит из разных частей, перемежаемых кастомным UI. В WPF это делается сравнительно просто, без привлечения тяжелой артиллерии.
Да, для развлекухи могу предложить поизучать дизайнер (и дизайн) SplitterContainer, познавательно.

ВВ>Скажи, а на чем ты раньше писал?

Много на чем, если ты про UI фреймворки. Начинал с TV, потом какой то сишный графический фреймворк с названием на букву Z, уже запамятовал, потом паскалевый OWL, потом он же, но сишный, потом VCL, потом Swing.

ВВ> Вин-формс, при всей его "неоднородности", "убогости" и проч. — огромный прогресс по сравнению с тем, что было до этого.

Во-первых это его в современных условиях лучше не делает, во-вторых на момент его релиза свинг уже порядочно времени как был зарелизен, а по сравнению с ним, ты уж извини, это все таки регресс.
Винформс, выйди он году в 95, был бы вполне адекватен времени, но в 2002 он явно устарел.

ВВ> Его убогость и неоднородность является отличной надстройкой над юзер32.

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

ВВ> Да, он неидеален в деталях, но базовая архитектура для "окошек" там хороша.

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

ВВ>И у меня ни разу не возникало желание выбросить на фиг вин-формс как ненужный уровень абстракции и вернуться "обратно", сообщения обрабатывать.

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

ВВ>Да и по поводу "большинство контролов имеют неудобный и примитивный API для взаимодействия с состоянием" — это вы, батенька, зажрались.

Ничуть. На дворе конец 2008 года. Мы тут всякие линки обсуждаем, asp.net mvc, а в винформсах все каменный век.

ВВ> У меня вот культурный шок был, когда я увидел ту же модель событий в вин-формс.

Ну, видимо мое предположение было верным.

ВВ>Сейчас это конечно уже не так воспринимается.

Еще раз повторяю — в 2002 оно тоже воспринималось "не так".

ВВ>Вы хотите увидеть модный фреймворк на его основе?

Я хотел его увидеть в 2002, а сейчас есть WPF.

ВВ> Это вряд ли. Но вин-формс это ИМХО лучшая надстройка над юзер32 что есть сейчас.

Cyberax утверждает, что не лучшая. Ну и того, что я знаю про wxWidgets, тоже хватает, чтобы усомнится в этом утверждении.

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

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

Ты удивишься, но с лесом if-ов и свитчей "боролись" посредством виртуальных функций не далее, как лет 10-12 назад. Что-то победы так и не случилось. Сейчас есть новая игрушка для решения этой проблемы, только это не pattern matching, конечно. Я имею в виду функции высших порядков. Проблемы будут ровно те же самые, что и с виртуальными функциями — тоже придётся дробить код на кусочки, с той лишь разницей, что в случае ОО-стиля мы оперируем "классами", а в FP — функциями. Функции, само собой, несколько мельче, чем классы, но проблема разбиения абстракции, в которую, в общем-то, мейнстрим и ткнулся, остаётся той же самой.

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

ГВ>>>>if/switch не предполагают изменения состояния. Pattern matching это что по-твоему, как не завуалированный if?
IT>>>if/switch не возвращающие значение и не меняющие состояния бесполезны и безсмысленны.
ГВ>>Упс. Так они и не возвращают значение, и не меняют состояние.
IT>Вот именно. Т.е. они вообще ничего не делают. И поэтому бесполезны.

На колу мочало, начинай сначала.

ГВ>>Ну, закрутилась шарманка. С чего ты взял, что в императиве входные данные обязательно модифицируются? Ничего подобного. Они могут модифицироваться, но это совершенно не обязательно.
IT>А почему именно входные данные. Модифицируется контекст, а в императиве это не только входные данные.

Опять таки, это вовсе не обязательно.

ГВ>>Расскажи это авторам pattern matching, COND.
IT>Pattern matching как раз великолепно возвращает данные. Аж со свистом.

Да ну? Я-то, грешным делом, привык думать, что pattern matching — это только подсахаривание выбора тела функции в зависимости от параметров. Где ты там нашёл возвращаемое значение? Я тоже хочу!

P.S.: Разговор начинает напоминать апологию ОО — тогда процедурному стилю тоже приписывались все мыслимые и немыслимые негативные качества, которые ему, якобы, имманентны.

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

ГВ>Да ну? Я-то, грешным делом, привык думать, что pattern matching — это только подсахаривание выбора тела функции в зависимости от параметров. Где ты там нашёл возвращаемое значение? Я тоже хочу!

ПМ назвать подсахариванием можно только с большой натяжкой. А возвращаемое значение — преставь себе, что в switch в каждом case стоит return. Осталось только превратить полученную функцию в локальный кусок кода и ты получишь ответ.

ГВ>P.S.: Разговор начинает напоминать апологию ОО — тогда процедурному стилю тоже приписывались все мыслимые и немыслимые негативные качества, которые ему, якобы, имманентны.

Возвращаемые значения у if или switch это совсем не признаки функционального стиля, а очень даже особенности синтаксиса конкретных языков. И никто, кстати, не мешает один раз написать функцию R If<R>(Func<bool> predicate, Func<R> then, Func<R> else), если уж в языке if не возвращает значения и тернарного оператора нет. В PL/SQL, кажись, так и сделали.
Опять же, есть ведь еще и итераторы (привет лиспу), где if заменяется when/filter/как-там-еще.

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

ГВ>>Да ну? Я-то, грешным делом, привык думать, что pattern matching — это только подсахаривание выбора тела функции в зависимости от параметров. Где ты там нашёл возвращаемое значение? Я тоже хочу!

AVK>ПМ назвать подсахариванием можно только с большой натяжкой.

Ну а что там ещё сверх if?

AVK>А возвращаемое значение — преставь себе, что в switch в каждом case стоит return. Осталось только превратить полученную функцию в локальный кусок кода и ты получишь ответ.

Да я это представляю вполне.

ГВ>>P.S.: Разговор начинает напоминать апологию ОО — тогда процедурному стилю тоже приписывались все мыслимые и немыслимые негативные качества, которые ему, якобы, имманентны.

AVK>Возвращаемые значения у if или switch это совсем не признаки функционального стиля, а очень даже особенности синтаксиса конкретных языков. И никто, кстати, не мешает один раз написать функцию R If<R>(Func<bool> predicate, Func<R> then, Func<R> else), если уж в языке if не возвращает значения и тернарного оператора нет. В PL/SQL, кажись, так и сделали.

Я примерно это и имел в виду, когда говорил, что if/switch несложно приписать возвращаемые значения.

AVK>Опять же, есть ведь еще и итераторы (привет лиспу), где if заменяется when/filter/как-там-еще.

Что-то не догоняю, а при чём они здесь?

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

AVK>То и значит. Каждый тег имеет вполне конкретное, присущее самому HTML значение. Тег же в XAML несет в себе довольно мало семантики, в основном это увязка с его компонентной моделью, которая неизмеримо более примитивна, нежели HTML. Все остальное навешивает уже конкретный фреймворк, который XAMLом пользуется.

Т.е. разница в том, что XAML более прост как язык разметки, чем HTML? В чем "конкретность" HTML? Его описания могут транслироваться и транслируются во что угодно, от окошек вин32 до "нарисованных красивостей". И там и там мы имеем описание именно представления, конкретного представления, стилей и пр.

ВВ>> Конкретную для кого?
AVK>Для всех.
ВВ>> Кроме общих слов есть что-нибудь сказать?
AVK>Это не общие слова, это вполне себе конкретика.
ВВ>>HTML — язык разметки, описывающий структуру страницы, используемые на ней элементы и их визуальное представление.
AVK>Ну вот видишь, ты сам все знаешь.
ВВ>> XAML делает то же самое абсолютно.
AVK>Нет. Ничего этого в XAML нет. Термины XAML это: меппинг пространства имен, компоненты, свойства, присоединенные свойства, контент.

XAML описывает структуры, используемые компоненты, их представление. Нет?

ВВ>> Можешь называть это "форматом сериализации" или как-то иначе — суть от этого не изменится.
AVK>Суть конечно не изменится, чего бы я не называл. Главное, что эта суть по факту совсем не та суть, что в HTML.
ВВ>> Про HTML я тоже могу сказать, что это формат сериализации объектной модели документа, и что?

AVK>И все. Даже если это так (а это не так), то это не просто формат сериализации документа, это формат вполне конкретного документа. Ни для чего другого он не годен.

А для чего еще годен XAML кроме как быть "форматом сериализации" конкретного "документа"?

ВВ>>Мы вообще о контролах говорим? Или как? Я с таким явлением как способ расширения функционала контролов "вообще" не знаком.
AVK>Что, никогда не наследовался от контролов винформсов? А если наследовался, не скажешь с какой целью?

Наследовался. Именно с этой целью. Но ты знаешь, не так уж и часто.

ВВ>> И что такое расширение?
AVK>Словарик руского языка подарить?

Могу с тобой поменяться на учебник логики. Заодно разберешься, чем "вообще" отличается от "в частности". И если "в частности" надо наследоваться для расширения функционала, это не означается "вообще" это надо делать.

ВВ>>Чтобы "расширить" DataGridView — я напишу собственный тип ячейки/колонки.
AVK>Ага, это единственный контрол, который хоть что то из себя в плане дизайна представляет.
ВВ>>Для изменения поведения некоторых контролов — например при валидации ошибок — я буду использовать совершенно отдельный такой проперти-провайдер.
AVK>Вот только, скажем, код отработки default button и ее modal result намертво прошит в код Form.

И кто-то при этом мешает переопределить modal result?

ВВ>>Да и еще помнится только взяв в руки вин-формс в году этак 2003 я делал owner-draw меню без всякого наследования, а через отдельный такой класс-адаптер.
AVK>Поздравляю. К сожалению, отдельные моменты не исключают общей печальной ситуации.

Вот только эти "отдельные моменты" почему-то очень во многих случаях работают.

ВВ>>Слушай, а для того, чтобы красивый тултип к контролу добавить — тоже небось наследоваться придется?
AVK>Если ты будешь разговаривать в таком тоне, я общение с тобой закончу. Не надо дурачка изображать, ты все прекрасно понял.

Не знаю, кто тут изображает "дурачка". Ты когда ScintillaWrapper как там конкретно контрол создавал, не вспомнишь?

ВВ>>Как хендл связан с агрегацией, а?
AVK>А ты попробуй отнаследовать свой контрол от Control и агрегировать в нем функционал, скажем, TreeView.

1. Controls.Add
2. override CreateParams

ВВ>>Расскажи какие сценарии реюза тебе требовались, и ты не смог их реализовать на вин-формс.

AVK>Например когда шаблон UI не квадратный кусок, а состоит из разных частей, перемежаемых кастомным UI. В WPF это делается сравнительно просто, без привлечения тяжелой артиллерии.

Что такое "состоит из разных частей, перемежаемых кастомным UI"? Я честно пытался представить, что это значит, но, увы, не получилось

AVK>Да, для развлекухи могу предложить поизучать дизайнер (и дизайн) SplitterContainer, познавательно.

SplitContainer? И что там? То, что он убоговат с первого взгляда видно. Так напиши свой
Меня, кстати, он вполне устраивал.

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

Мне вот интересно — вы все серьезно считаете, что сравнение кросс-платформенного фреймворка и надстройки над конкретной платформой — это корректно? И непонятно какие преимущества дает "одноплатформенный" фреймворк?

AVK>Винформс, выйди он году в 95, был бы вполне адекватен времени, но в 2002 он явно устарел.

Не знаю, как у вас там со свингами и прочими джазами, но в вин-среде и в 2002 вин-формс выглядел весьма и весьма внушительно. По сравнению с тем, что предлагала МС до этого — огромный прогресс. Архитектура завязанная на модель событий — очень логичная для юзер32.

ВВ>> Его убогость и неоднородность является отличной надстройкой над юзер32.
AVK>Оно тут не причем. Почти все пакости user32 легко замазываются. Опять же, обрати внимание, большинство тех проблем, что я перечислил, никакого отношения к user32 не имеют. К примеру, байндинга в нем просто нет. Отсутствует как класс. Что не помешало вкрячить коллекцию DataBindings в интерфейс базового контрола.

Ты перечислил проблемы в стиле "примитивная компонентная модель" или "неудобный и примитивный АПИ для взаимодействия с состоянием". В таком стиле эту тему можно перетирать бесконечно. А вот конкретные примеры что-то не выглядят убедительно.

ВВ>> Да, он неидеален в деталях, но базовая архитектура для "окошек" там хороша.
AVK>Детали фигня, благо поставщики компонентов переписывают чуть ли не все контролы. Проблема именно в базовой архитектуре. Главное чудовище это класс Control, а не куча его наследников.

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

ВВ>>И у меня ни разу не возникало желание выбросить на фиг вин-формс как ненужный уровень абстракции и вернуться "обратно", сообщения обрабатывать.
AVK>Это, видимо, потому что опыт ковыряния у тебя в этой каке небольшой.

Любое мнение отличное от вашего возможно лишь в силу незнания, ограниченности или недостаточного опыта. Это несомненно.

AVK>Опять же, еще большая кривизна user32 никак не делает дизайн винформсов хорошим.

Делает. Делает его лучше чем работа напрямую с юзер32. Что уже хорошо. Хотя бы то, что в худшем случае не мешает. Чего я не могу сказать про веб-формс и тамошний "низкий уровень" в виде обработки реквестов напрямую.

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

ГВ>Ты удивишься, но с лесом if-ов и свитчей "боролись" посредством виртуальных функций не далее, как лет 10-12 назад.

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

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

ГВ>Функции, само собой, несколько мельче, чем классы, но проблема разбиения абстракции, в которую, в общем-то, мейнстрим и ткнулся, остаётся той же самой.

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

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

ВВ>>>Мне казалось, что ФП предполагает нечто иное.
G>>Что именно?
ВВ>Изменение стереотипов. Можно, конечно, рассуждать, что императивность не искоренима в принципе и везде есть чуточку "императива" — пожалуй и так, но суть-то не в этом.

Ну как всегда — как же без апелляции к стереотипам, которые "надо менять" почему-то. Освободи свой разум, ж... освободится сама! (c) Для сведения: императивность неискоренима вовсе не из-за каких-то надуманных стереотипов, а из-за того, что компьютер в своей основе — сугубо императивный агрегат, бесконечно разрушающий свою собственную память. Понимаешь? До тех пор, пока ЦПУ не станет чисто функциональным, а RAM не начнёт возникать из космической пыли по мановению волшебной палочки — императивщина останется неискоренимой в принципе.

В то же время, функциональный стиль, как облегчающий распараллеливание (это едва ли не единственное значимое преимущество FP) именно сейчас оказался на пике моды из-за того, что развитие процессоров упёрлось в физические ограничения, поэтому-то в майнстрим понеслась идея FP. Не только поэтому, разумеется, но в некоторой немалой части, ИМХО.

ВВ>Если новая концепция программирования не заставляет тебя думать и писать по-другому, а лишь помогает что-то там "распараллелить", то в recycle bin эту концепцию.

Парадокс в том, что FP — это чудовищно не новая концепция. Просто до невероятности не новая. Не новая настолько, что называть её новой — это нарываться на шутки в свой адрес. "Новое" сейчас только жужжание вокруг FP и повсеместное внедрение лямбд с сопутствующими замыканиями. Больше новизны — ни на грош.

ВВ>У вас же получается, что мы думаем по-старому, пишем по-старому ("по-старому" кстати далеко не эквивалетно "плохо"), и при этом используем какие-то "фишки" функционального стиля, при этом считая, что "функциональщина" больше ничего не дает.
ВВ>А вы пробовали взять?

Да что там брать-то, кроме способа разбиения абстракций и некоторого сокращения записи из-за возможности определения функций "по месту", присущего FP-языкам? А, нет. Ещё можно "взять" относительную близость сугубо математической нотации. Правда, что тут от кого "берётся" — математика от FP или FP от математики — вопрос спорный.

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

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

ВВ>Обычно "изменение стереотипов" приводит к тому, что по-старому уже думать не хочется.

Менять стереотипы неприятно потому, что замена одного стереотипа на другой раньше или позже выливается в замену шила на мыло. Меняешь одни шоры на другие — в чём кайф?

ВВ>Да, всем нам приходится писать на старых языках, но мы же при этом не делаем вид, что в них доступны все прелести ФП. Да и применять ФП-техники можно. Точно также я в свое время применял некоторые ОО-техники в ВБ6, когда приходилось писать на нем. Но ведь он от этого не становился объектно-ориентированным?

ВБ6, как раз — вполне ОО-язык. Пусть и ограниченный в некотором роде.

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

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

Очевидно, что смысл такой функции заключён в её использовании ради реализации определённых абстракций. Я надеюсь, ты не думаешь, что классы/объекты делают только ради ОО-стиля, а процедуры — только ради императивного стиля самого по себе.

ВВ>Получается, что у тебя часть кода в императивном стиле, часть кода — как бы клиентская — в фукциональном стиле. А где граница-то между тем и другим?

А зачем она, эта самая граница? ИМХО, всё ограничивается удобством/очевидностью/другими практическими аспектами использования. Стиль ради стиля, это, как-то, неправильно.

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

ГВ>>Ты удивишься, но с лесом if-ов и свитчей "боролись" посредством виртуальных функций не далее, как лет 10-12 назад.
ВВ>Вообще полиморфизм классов теоретически действительно позволяет выкинуть это барахло. А вот на практике — да, не получится. Тут и пробовать особо не надо. Ибо очень уж тяжеловесен ООП для этого.

Ерунда. Дроблению абстракции мешают, как это ни странно, организационные моменты, а не тяжеловесность ООП.

ГВ>>Функции, само собой, несколько мельче, чем классы, но проблема разбиения абстракции, в которую, в общем-то, мейнстрим и ткнулся, остаётся той же самой.

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

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

Сейчас я вижу ситуацию, с точностью до деталей повторяющую вакханалию вокруг ООП. Вот всё один в один то же самое: точно так же предлагается выбросить всё и переписать на [новый язык], которому приписываются мистические свойства и точно так же "старый" [язык, стиль, подход] объявляется [исчадие ада, след Ктулху, зашоренность мозга]. Совершенно же аналогично истории с ООП есть свой набор success stories.

То есть, чисто внешне ситуация выглядит повторяющей то, что уже происходило не раз. Курьёзный момент, что во времена распространения ООП вузы преподавали как раз функциональные языки, а сейчас положение склоняется к зеркальному: в вузах ООП, на практике — FP. Совсем не курьёзный момент — это то, что людей со специальным образованием становится банально меньше, что как раз служит аргументом в пользу сомнений относительно применимости чисто математических фишек FP.

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

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

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

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

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

ВВ>А можно по-конкретнее? Что там неудобно? Что сложно реализовать?
Любая анимация состояния — это pain. Любые игры с выходом за пределы своего clip rect типа теней, обводки, и прочих glow — pain. Масштабирование — pain. Композитные контролы — тройной pain.

Cкорее возникает вопрос — а что там реализовать легко и удобно. Практика показывает, что легко и удобно делать только примеры для книжек "как не должен быть устроен UI". Более-менее нормальные решения делать уже сложно. Для хороших, повторюсь, нужно выкидывать весь стандартный стек и брать свой.

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

ВВ>В таком случая определишь, что ты утверждаешь.
Я вообще про WTL ни слова не говорил. Откуда появился WTL?

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

ВВ>Ну правильно. HTML + браузер. Вот с одной стороны язык разметки, описывающий представления и в то же время отделенный — я бы даже сказал "отдаленный" — от отрисовки. HTML в данном случае можно понимать как некий язык разметки, к которому тот же XAML довольно близок идеологически.
ВВ>Но если все так просто, то почему ж классические веб-технологии, где как раз и есть что работа с HTML врукопашную, приводят к такой каше в коде?
У кого они к этому приводят? У нормальных пацанов никакой каши в коде нету. См. jQuery. А у тех, у кого каша в голове, она же всегда будет в коде. Независимо от платформы. Раньше они писали логику в Button1Click, теперь — в a.onclick.

ВВ>Только вот в итоге все равно непонятно, что в вин-формс не нравится.
Убогая архитектура. Я уже три дня рассказываю, что в нем плохо. Это для кого?
ВВ>Помнится, несколько постов назад ты утверждал, что "никто не защищает веб-формс". Теперь тактика поменялась? Решил путем аналогий начать, так сказать, апологию веб-форм?
Нет. Я, в отличие от некоторых участников данной дискуссии, что думаю, то и пишу. Никаких скрытых мотивов у меня нету. Поясняю еще раз, медленно и без намеков:
1. ВебФормз — отстой.
2. ВинФормз — отстой.

Еще вопросы?
ВВ>У меня вот складывается ощущение, что ты не какую-то точку зрения пытаешься доказать, потому что судя по всему ее нет — или ты ее по крайней мере очень хорошо скрываешь — а то, что твой оппонент идиот.
Я ничего не скрываю. Это ты почему-то хочешь найти в моих словах какой-то неожиданный смысл. Нет, они означают ровно то, что означают. Когда я пишу, что ASP.NET — хорошая платформа, я имею в виду именно то, что это хорошая платформа. А не то, что размещение бизнес-логики в System.Web.UI.Page.OnLoad — хорошая идея. Когда я пишу, что винФормз предлагает хреновую модель для построения GUI — я именно это и имею в виду.
Причем к user32 у меня претензий, в общем-то, нету. Потому что она, в отличие от comctl32, не навязывает идею строить UI из микроокон. Критиковать user32 за плохую модель UI — то же самое, что критиковать сокеты за неудачную модель постбеков.

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