Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Мне вот непонятно, что за задача такая — помножение матриц. И, думаю, не только мне. Для чего/для кого она делается?
PD>Не обижайся на то, что я сейчас скажу, ладно ? Я вовсе не хочу ни тебя, ни кого-то еще обидеть. Я с уважением отношусь к любым задачам.
PD>В этом твоем ответе — суть проблемы. Тебе и другим — действительно непонятно. В задачах бизнеса (как я их определил) — это действительно не нужно. Если речь идет о создании сайта — это скорее всего не нужно. Если речь идет о системе управления заводом — может быть, тоже. И т.д.А поскольку большинство этим бизнес-задачами и занимается, то ему (большинству) это действительно непонятно. Оно как-то подсознательно уверено, что то, чем они занимаются — и есть единственно верное программирование, а то, что ему не нужно — вообще не нужно.
В задачах бизнеса без ЭТОГО никуда. Даже неразработчику программы, а пользователю. Закладыватся на прогноз полученный по непонятному алгоритму? Увольте-с. Так что если не уметь, то представление иметь следует обязательно.
Здравствуйте, konsoletyper, Вы писали:
ВВ>>Как объяснить бизнесу, что реализация фичи Х занимает 3 часа, а для фичи У надо все на фиг переписать? С т.з. клиента это совершенно нелогично. K>А вот так и приходится. Постоянно. Жизнь у айтишников такая.
Да ты что? У нас тут один "айтишник" бегает — мне казалось, он сервера чинит. Оказывается, вон у него жизнь какая.
Технология должна упрощать жизнь. Если она не упрощает, а наоборот усложняет, то на фиг нужна такая технология.
ВВ>>Вот кстати в вин-формах ситуация значительно лучше. Я там контрол могу хоть раком поставить. При этом "отрисовать все самому" мне в голову придет в последнюю очередь. Есть конечно ограничения, но в значительно меньшей степени. K>В Windows Forms точно такая же проблема. И ограничения там мешают в неменьшей степени. Самой гибкой "технологией" оказалась бы "попиксельный рендеринг с помощью XSLT".
Это какие ограничения в windows forms мешают? В Windows Forms довольно удачная для Win32 архитектура, построенная на событиях, инкапсулирующих сообщения Windows. Программировать под Windows Forms значительно проще и приятнее чем, скажем, под MFC. Да и "попиксельный рендеринг" через GDI+ реализован довольно удачно. В Web Forms попытались изобразить то же самое, что и Win Forms.
Если до кого-то не доходит, что веб-приложение не должно иметь такую же архитектуру как и вин-приложение, то это его проблемы — пусть и дальше изображает из себя "айтишника".
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Технология должна упрощать жизнь. Если она не упрощает, а наоборот усложняет, то на фиг нужна такая технология.
Ну-ну. Вот как раз Web Forms упрощает жизнь. В 99% случаев. А в 1% можно 1) найти workaround 2) сторонний контрол. Да, можно сказать, что самая крутая технология — это непосредственно генерить тексты на ассемблере. Там простор действий большой. Но удобно ли это? Может, лучше мириться с небольшими ограничениями ради того, чтобы разработка была простой?
Вот XSLT, за который ты цепляешься, при всей своей мощности, тоже обладает рядом недостатков. Году в 2004-м (я тогда ещё не работал в компании) народ у нас пытался заюзать XSLT для кодогенерации. В результате столкнулись с тем, что не получалось решить банальные проблемы, вроде генерации аналога имени в pascal и camel casing. В итоге пришлось написать свой кодогенаратор на основе своего XML-языка. Кстати, сейчас мы сходимся во мнении, что для подобных задач лучше иметь специальный язык шаблонизации, не основанный на XML.
ВВ>>>Вот кстати в вин-формах ситуация значительно лучше. Я там контрол могу хоть раком поставить. При этом "отрисовать все самому" мне в голову придет в последнюю очередь. Есть конечно ограничения, но в значительно меньшей степени. K>>В Windows Forms точно такая же проблема. И ограничения там мешают в неменьшей степени. Самой гибкой "технологией" оказалась бы "попиксельный рендеринг с помощью XSLT".
ВВ>Это какие ограничения в windows forms мешают? В Windows Forms довольно удачная для Win32 архитектура, построенная на событиях, инкапсулирующих сообщения Windows. Программировать под Windows Forms значительно проще и приятнее чем, скажем, под MFC. Да и "попиксельный рендеринг" через GDI+ реализован довольно удачно. В Web Forms попытались изобразить то же самое, что и Win Forms.
Это в Windows Forms нету ограничений? Тогда пример приведу. Вот есть TreeView. Он может отображать в узлах дерева иконку и текст (а ещё, если не ошибаюсь, checkbox). Чтобы отобразить в нём что-то нетривиальное (например, смарттеги к узлам добавить), приходится либо извращаться, либо выкидывать контрол и писать свой или брать сторонний. Вот если бы была возможность класть в узлы дерева любой контрол, то сам по себе TreeView решал бы гораздо более широкий класс задач. Но, к сожалению, в рамках WinForms этот недостаток непреодолим в силу Windows API. Так что нужно строить что-то поверх. Например, посмотреть в сторону WPF.
Попиксельный рендеринг — это хорошо. Вот только громоздко и неудобно. Я тебе так же могу предложить использовать твой любимый XSLT для того, чтобы рендерить свой WebForms контрол. Почему бы нет?
ВВ>Если до кого-то не доходит, что веб-приложение не должно иметь такую же архитектуру как и вин-приложение, то это его проблемы — пусть и дальше изображает из себя "айтишника".
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Вернее, давайте я поправлюсь — тот ASP.NET, который начинается и заканчивается на IHttpHandler/IHttpModule — это отличная штука. А вот все что сверху...
Всё, что сверху тоже клаcсная штука. Но есть одно "но". В интерактивных веб-приложениях сложность использования технологий, гоняющих состояние туда-сюда между клиентом и сервером, растёт пропорционально навороченности пользовательского интерфейса. Но это проблема не WebForms конкретно, а вообще подхода. Состояние должно быть в одном месте, либо на клиенте, либо на сервере. На сервере его хранить невозможно в принципе, т.к. весь диалог идёт на клиенте, соответственно, единственный рецепт — это держать состояние на клиенте, т.е. переходить на javascript (чего не очень хочется) и AJAX, либо на сервелады и xbap.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>На сервере его хранить невозможно в принципе
Хорошо, что ты это не сказал ребятам из ZK (http://www.zkoss.org/), а то ведь бы они тогда не сделали свой фреймворк.
IT>т.к. весь диалог идёт на клиенте, соответственно, единственный рецепт — это держать состояние на клиенте, т.е. переходить на javascript (чего не очень хочется) и AJAX, либо на сервелады и xbap.
Держать состояние на клиенте — это тоже хорошая идея. И даже на JavaScript можно не переходить (см. Google Web Toolkit).
Здравствуйте, Cyberax, Вы писали:
IT>>На сервере его хранить невозможно в принципе C>Хорошо, что ты это не сказал ребятам из ZK (http://www.zkoss.org/), а то ведь бы они тогда не сделали свой фреймворк.
А как это у них работает в двух словах? Если это действительно возможно, то я легко откажусь от своих принципов
IT>>т.к. весь диалог идёт на клиенте, соответственно, единственный рецепт — это держать состояние на клиенте, т.е. переходить на javascript (чего не очень хочется) и AJAX, либо на сервелады и xbap. C>Держать состояние на клиенте — это тоже хорошая идея. И даже на JavaScript можно не переходить (см. Google Web Toolkit).
Можно, конечно, заниматься преобразованием серверного кода в javascript, но что-то мне пока не кажется этот путь наиболее эффективным.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
C>>Хорошо, что ты это не сказал ребятам из ZK (http://www.zkoss.org/), а то ведь бы они тогда не сделали свой фреймворк. IT>А как это у них работает в двух словах? Если это действительно возможно, то я легко откажусь от своих принципов
На сервере в сессии хранится реплика клиентского состояния. Обработчики событий на сервере поэтому работают "как будто на клиенте", а клиенту высылаются изменения в дереве контролов. Естественно, там учитывается, что может быть несколько окон браузера с несколькими табами и т.п.
С некоторыми оптимизациями работает даже вполне прилично. Хотя мне лично не нравится то, что сервер перестаёт быть stateless.
C>>Держать состояние на клиенте — это тоже хорошая идея. И даже на JavaScript можно не переходить (см. Google Web Toolkit). IT>Можно, конечно, заниматься преобразованием серверного кода в javascript, но что-то мне пока не кажется этот путь наиболее эффективным.
Конкретно GWT мне позволяет писать AJAX-приложения с такой же скоростью, что и обычные десктопные. Особо рулит использование автокомплита и обычного Java-отладчика внутри GWT-кода.
Здравствуйте, deniok, Вы писали:
D>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>В этом смысле — мб, и да, если знать Хаскель, конечно. Но меня вообще-то больше интересует эффективность его выполнения
D>Ключевым моментом, которого пока не касались в этой дискуссии, является высокоуровневая оптимизация, про которую никакой ассемблер не знает. Например, в Хаскелле есть дефорестация (list fusion). Вася взял список, применил к его элементам функцию f, получив другой список: D>
D>vasja lst = map f lst
D>
D>Петя взял васин код, и поэлементно применил к возвращаемому этим кодом списку функцию g D>
D>petja lst = map g (vasja lst)
D>
D>Оля взяла петин код, поэлементно применила к возвращаемому этим кодом списку функцию h D>
D>olja lst = map h (petja lst)
D>
D>Компилятор Хаскеля взял эту конструкцию с кучей промежуточных списков и оптимизировал в D>
D>olja_oplimized lst = map (h . g. f) lst
D>
D>Без единого промежуточного списка.
Довольно стандартная фича например для C++, это я недоразобрался или в плюсах есть потдержка функциональных фичей ? это не наезд , но например boost iterator adaptors именно так и работают.
Если существуют методологии позволяющие очень сильно повысить читабельность, уменьшить к-во, улучшить сопровождение и т.п. Я бы очень хотел об этом подробнее узнать.
Но я оцениваю вероятность такой ситуации близкой к нулю , потому что не встречал написанных революционно проектв типа FFMPEG или openCV или декодер jpeg2000.
Здравствуйте, Cyberax, Вы писали:
C>На сервере в сессии хранится реплика клиентского состояния.
Как хранится состояние строки ввода в браузере на сервере?
C>Обработчики событий на сервере поэтому работают "как будто на клиенте", а клиенту высылаются изменения в дереве контролов. Естественно, там учитывается, что может быть несколько окон браузера с несколькими табами и т.п.
C>С некоторыми оптимизациями работает даже вполне прилично. Хотя мне лично не нравится то, что сервер перестаёт быть stateless.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, minorlogic, Вы писали:
M>Если существуют методологии позволяющие очень сильно повысить читабельность, уменьшить к-во, улучшить сопровождение и т.п. Я бы очень хотел об этом подробнее узнать.
См. FP.
M>Но я оцениваю вероятность такой ситуации близкой к нулю , потому что не встречал написанных революционно проектв типа FFMPEG или openCV или декодер jpeg2000.
А как ООП революционно работает для проектов типа FFMPEG или openCV или декодер jpeg2000? Никак? Давайте откажемся от ООП!
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Всё, что сверху тоже клаcсная штука. Но есть одно "но". В интерактивных веб-приложениях сложность использования технологий, гоняющих состояние туда-сюда между клиентом и сервером, растёт пропорционально навороченности пользовательского интерфейса.
Ну вот скажи, тебе лично нравится идея сделать архитектуру веб-приложения по аналогии с Windows-приложением? Зачем WebForms делать по аналогии c WindowsForms?
Неужели и этот уровень абстракции тоже супер-полезен?
IT>Но это проблема не WebForms конкретно, а вообще подхода. Состояние должно быть в одном месте, либо на клиенте, либо на сервере.
Это особенность HTTP, и от нее никуда не уйдешь, ибо HTTP stateless.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, minorlogic, Вы писали:
M>>Если существуют методологии позволяющие очень сильно повысить читабельность, уменьшить к-во, улучшить сопровождение и т.п. Я бы очень хотел об этом подробнее узнать.
IT>См. FP.
Я читал предыдущий пост пере тем как ответить.
M>>Но я оцениваю вероятность такой ситуации близкой к нулю , потому что не встречал написанных революционно проектв типа FFMPEG или openCV или декодер jpeg2000.
IT>А как ООП революционно работает для проектов типа FFMPEG или openCV или декодер jpeg2000? Никак? Давайте откажемся от ООП!
ОПП просто восхитительно работает , см исходники Jasper или kakadu или JJ2000, это из тех что я точно знаю.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну вот скажи, тебе лично нравится идея сделать архитектуру веб-приложения по аналогии с Windows-приложением? Зачем WebForms делать по аналогии c WindowsForms? ВВ>Неужели и этот уровень абстракции тоже супер-полезен?
Что касается контролов, как средство инкапсуляции для рендеринга, то я не вижу в этом проблем. А вот с состоянием не получилось и это мне не нравится.
IT>>Но это проблема не WebForms конкретно, а вообще подхода. Состояние должно быть в одном месте, либо на клиенте, либо на сервере.
ВВ>Это особенность HTTP, и от нее никуда не уйдешь, ибо HTTP stateless.
Дело не в HTTP, дело в распределённости состояния.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, minorlogic, Вы писали:
M>>>Если существуют методологии позволяющие очень сильно повысить читабельность, уменьшить к-во, улучшить сопровождение и т.п. Я бы очень хотел об этом подробнее узнать.
IT>>См. FP.
M>Я читал предыдущий пост пере тем как ответить.
Тогда что именно не понятно?
M>>>Но я оцениваю вероятность такой ситуации близкой к нулю , потому что не встречал написанных революционно проектв типа FFMPEG или openCV или декодер jpeg2000.
IT>>А как ООП революционно работает для проектов типа FFMPEG или openCV или декодер jpeg2000? Никак? Давайте откажемся от ООП!
M>ОПП просто восхитительно работает , см исходники Jasper или kakadu или JJ2000, это из тех что я точно знаю.
И что там революционного?
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, minorlogic, Вы писали:
M>>>>Если существуют методологии позволяющие очень сильно повысить читабельность, уменьшить к-во, улучшить сопровождение и т.п. Я бы очень хотел об этом подробнее узнать.
IT>>>См. FP.
M>>Я читал предыдущий пост пере тем как ответить.
IT>Тогда что именно не понятно?
Я не говорил что мне что то непонятно.
M>>>>Но я оцениваю вероятность такой ситуации близкой к нулю , потому что не встречал написанных революционно проектв типа FFMPEG или openCV или декодер jpeg2000.
IT>>>А как ООП революционно работает для проектов типа FFMPEG или openCV или декодер jpeg2000? Никак? Давайте откажемся от ООП!
M>>ОПП просто восхитительно работает , см исходники Jasper или kakadu или JJ2000, это из тех что я точно знаю.
IT>И что там революционного?
Понятия не имею с чего ты взял? на мой взгляд ничего революционного там нет? Я имел ввиду написаноого в революцыонном стиле (FP например) из подобного рода проектов не встречал.
Здравствуйте, minorlogic, Вы писали:
M>Довольно стандартная фича например для C++, это я недоразобрался или в плюсах есть потдержка функциональных фичей ? это не наезд , но например boost iterator adaptors именно так и работают.
Как "так"?
В GHC оптимизатор сначала прочитывает Rewriting Rules типа
{-# RULES
"map/map" forall f g xs . map f (map g xs) = map (f . g) xs
#-}
после чего проходясь по исходному коду заменяет левую часть на правую. Такие "синтаксические" трансформации допустимы поскольку функциональный код "чистый", то есть не имеет побочных эффектов. Можно забацать любую трансформацию — желательно, правда, доказать предварительно, что она не меняет семантики .
А для list fusion в GHC используют, конечно, не примитивный map/map, а
{-# RULES
"fold/build" forall k z (g::forall b. (a->b->b) -> b -> b) .
foldr k z (build g) = g k z
"foldr/augment" forall k z xs (g::forall b. (a->b->b) -> b -> b) .
foldr k z (augment g xs) = g k (foldr k z xs)
...
#-}
и ещё десяток более специальных правил. Причём библиотечные функции для списков реализованы таким образом, чтобы максимально облегчить deforestation при включённом оптимизаторе.
Здравствуйте, IT, Вы писали:
IT>Что касается контролов, как средство инкапсуляции для рендеринга, то я не вижу в этом проблем. А вот с состоянием не получилось и это мне не нравится.
Проблема тех же контролов в том, что с одной стороны это "шаблоны", уровень некоторой абстракции над HTML — с другой, стоит чуть сойти с проторенных рельс, и вокруг этих самых шаблонов вырастают тонны HTML-я. Т.е. в общем случае под видом контрола мы получаем... ну что-то вроде макроса в С, причем по своей функциональности и методу работы они практически аналогичны. А хочется ведь макросов как в Немерле
Потом ты вот говоришь, что тебе не нравится как организована работа с состоянием. А ведь viewstate — одна из основных фишек контролов. Причем он всегда или есть или нет. Т.е. я не могу его отключить частично, если мне нет нужны дублировать данные контрола и перегружать страницу.
А AJAX тоже не панацея. Особенно то, как это сделано в ASP.NET. Кол-во телодвижений для обновления некой части страницы через updatepanel примерно аналогично реализации того же самого через XMLHTTPRequest напрямую. И в чем фича?
Ну это ладно, вот "добавили" аякс, люди "в массе" своей решили, что у них приложения будут работать благодаря нему в разы быстрее, а в итоге все почему-то работает даже медленнее. Не видел например веб-морду у Remedy? Она целиком на аяксе (не асп-нет) и блин как она тормозит!
ИМХО дело не в технологии "передачи" состояния — ибо все равно ты его будешь передавать на сервер в конечно счете. Проблема в том, что построив "абстракцию" над HTTP, внутри АСП.НЕТ все те же формы, поля и пр. — т.е. методы работы с данными самые что ни на есть древние.
Интереснее было бы, мне кажется, структировать сам формат состояния да и вообще данные, которые гоняются туда сюда. Например, чтобы это была не форма вида key=value&k2=value2..., а XML документ, который в свою очередь можно всегда проверить по XML-схеме, всегда можно показать используя различные стайлшиты (XSLT), а уж технология передачи — это мне кажется дело вторичное.
Здравствуйте, IT, Вы писали:
C>>На сервере в сессии хранится реплика клиентского состояния. IT>Как хранится состояние строки ввода в браузере на сервере?
Адресной строки или поля ввода?
Если поле ввода, то хранится как простой String в модели страницы. Поля ввода синхронизируются при совершении действия, требующего вызов серверного события. Т.е. у тебя форма с 10 полями, ты их как-то редактируешь на клиенте, а когда нажимаешь кнопку "OK" изменённые поля уходят на сервер вместе с событием "кнопка нажата". На сервере изменения вливаются в модель, а потом вызывается обработчик.
Если повесить обработчик на событие "фокус потерян", то синхронизироваться будет после потери фокуса (для валидации, например).
Если нам не помогут, то мы тоже никого не пощадим.
