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

ВВ>>Можно ссылку на суперкомпилятор для C#?
S>Ccылку на джаву дали.

И что мне с ней делать? Молиться на нее?

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

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

ВВ>>Когда напишут — тогда и поговорим. А пока все абстракции — реализуемые средствами языков на .NET — о которых здесь и речь неизбежно несут оверхед.
S>Вот-вот. Когда напишет — тогда и поговорим. А пока на ассемблере воспроизвести банальную ASP.NET страничку, которая обращается к базе, веб-сервису и локальной файлухе — совершенно нереально. Я имею в виду — со сравнимой с ASP.NET эффективностью: то есть везде IO Completion Ports, тред пул по максимуму и т.п.

Да, ослиный ASP.NET — это гениальный пример для сравнения. Ничего лучше чем дебильный конструктор сайтов и подобрать нельзя. Может, лучше программирование на асме вообще сравнить с InfoPath-ом? Ведь какие там формочки, какие абстракции.
А может, это — давайте тогда все на свете на АСП-НЕТ писать? Ведь АСП-НЕТ рвет на части асм по своей эффективности. Чет мужики еще не доперли что надо все на АСП-НЕТ переводить.

Abstraction gain — он в голове. И это хорошо, что он в голове, а не в другом месте. И не надо его из головы куда-то перекладывать.

S>А пока все эти суперомтизации — реализуемые трюками с регистрами, SSE, и переупорядочиванием команд — о которых здесь и речь неизбежно несут оверхед в стоимости разработки.

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

В основном согласен.


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

+1

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

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

F>Я ведь тоже могу рассказать, какая это жуткая задача строить веб страницы — у меня сотни запросов в секунду, на каждый запрос надо подготовить данные по 20000 сущностей, а их все надо взять из базы, а для этого мне надо 200 запросов, а потом все эти данные обработать непростым алгоритмом ( 300 мс на каждую сущность) и все это нужно уложиться в полсекунды для каждого пользователя (которых тысячи). Это же уму непостижимо какая сложная вычислительная задача!!!

А я и не спорю.

F>А потом рассказать, как я жутко оптимизирую алгоритм, и он уже не 300мс тратит, а всего 50мс (но 20000 объектов —
F>это все равно слишком долго обрабатывается). Ах, какие стали ужасные неэффективные средства.

Знакомо мне все это... Ох, как знакомо. Без БД, правда.

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

Твое счастье, что можно кешировать. А у меня абсолютно нет.


F>Ты часто путаешь технические задачи и отдельные детали решения с собственно бизнес-задачами.

А вот для меня лни просто равны. Задачи такие...

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

Вот именно

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

Бывают.



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

Упаси боже. Я же просил — не обижаться. У меня такого и в мыслях не было.

F>Мы, на самом деле, многое понимаем.
F>Да еще и высказать можем

Здравствуйте, Воронков Василий, Вы писали:
ВВ>И что мне с ней делать? Молиться на нее?
Ну, например понять, что применение той же техники для C# принципиальных проблем не имеет.

S>>В таком случае, нужно отказаться от муссирования рассуждений типа "теоретически программист может вручную на ассемблере заоптимизировать всё насмерть"
ВВ>Ну правильно, ведь на ассемблере никто ничего не пишет, им пугают детей на ночь, а мы тут уже вовсю дотнет-приложения "суперкомпляторами" компилируем.
Этот понос — он к чему?

ВВ>Да, ослиный ASP.NET — это гениальный пример для сравнения. Ничего лучше чем дебильный конструктор сайтов и подобрать нельзя.
А что в нём ослиного? Это не дебильный конструктор сайтов, а лучший в мире фреймворк для построения высокопроизводительных веб-приложений. Это так, к слову о.

ВВ>Может, лучше программирование на асме вообще сравнить с InfoPath-ом? Ведь какие там формочки, какие абстракции.
Ну, с таким уровнем представлений вы можете асм хоть с копченой рыбой сравнивать.

ВВ>А может, это — давайте тогда все на свете на АСП-НЕТ писать? Ведь АСП-НЕТ рвет на части асм по своей эффективности. Чет мужики еще не доперли что надо все на АСП-НЕТ переводить.
Еще раз медленно повторяю: пусть твои мужики воспроизведут на асме хотя бы один пример из самплов к Рихтеровской Power Threading Library. И посмотрим, кто кого порвёт по эффективности.
ВВ>Abstraction gain — он в голове. И это хорошо, что он в голове, а не в другом месте. И не надо его из головы куда-то перекладывать.
Еще раз, медленно, поясняю: abstraction gain — вполне конкретная штука, и она существует. В частности специализация абстрактного кода под аппаратную платформу в момент исполнения, она же JIT. В частности, специализация абстрактного кода под реальные данные в момент сборки, она же суперкомпиляция.

Поменьше эмоций, побольше мыслей.

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

ВВ>>И что мне с ней делать? Молиться на нее?
S>Ну, например понять, что применение той же техники для C# принципиальных проблем не имеет.

И что мне от этого понимания? C# крут, потому что теоретически возможно написать супер-компилятор? Теоретически много чего возможно.

ВВ>>Да, ослиный ASP.NET — это гениальный пример для сравнения. Ничего лучше чем дебильный конструктор сайтов и подобрать нельзя.
S>А что в нём ослиного? Это не дебильный конструктор сайтов, а лучший в мире фреймворк для построения высокопроизводительных веб-приложений. Это так, к слову о.

"Лучший" — это по результатам голосований на MSDN? С чем его сравнивали? Какие перформанс тесты проводили?

ВВ>>Может, лучше программирование на асме вообще сравнить с InfoPath-ом? Ведь какие там формочки, какие абстракции.
S>Ну, с таким уровнем представлений вы можете асм хоть с копченой рыбой сравнивать.

Ну да, а сравнить ассемблер и ASP.NET — это видимо правила хорошего тона.

ВВ>>А может, это — давайте тогда все на свете на АСП-НЕТ писать? Ведь АСП-НЕТ рвет на части асм по своей эффективности. Чет мужики еще не доперли что надо все на АСП-НЕТ переводить.
S>Еще раз медленно повторяю: пусть твои мужики воспроизведут на асме хотя бы один пример из самплов к Рихтеровской Power Threading Library. И посмотрим, кто кого порвёт по эффективности.

Зачем?

ВВ>>Abstraction gain — он в голове. И это хорошо, что он в голове, а не в другом месте. И не надо его из головы куда-то перекладывать.
S>Еще раз, медленно, поясняю: abstraction gain — вполне конкретная штука, и она существует. В частности специализация абстрактного кода под аппаратную платформу в момент исполнения, она же JIT. В частности, специализация абстрактного кода под реальные данные в момент сборки, она же суперкомпиляция.

А если аппаратная платформа вообще всего одна и другой быть не может?
Или abstract gain он присутствует по определению, что бы мы не писали? Ну по фиг, да, есть проблем с производительностью? — добавить дополнительный уровень абстракции, и все станет шоколадно.

S>Поменьше эмоций, побольше мыслей.

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

ВВ>И что мне от этого понимания? C# крут, потому что теоретически возможно написать супер-компилятор? Теоретически много чего возможно.
Совершенно верно. Я и говорю — теоретически можно и Http Handler на ассемблере написать.
S>>А что в нём ослиного? Это не дебильный конструктор сайтов, а лучший в мире фреймворк для построения высокопроизводительных веб-приложений. Это так, к слову о.
ВВ>"Лучший" — это по результатам голосований на MSDN? С чем его сравнивали? Какие перформанс тесты проводили?
Лучший — это по результатам моего личного опыта. Сравнивали с JSP, ASP, PHP, Python. С наколеночными CGI на C и С++. Тесты проводили самые разнообразные. Кроме того, я немножко представляю себе, как все эти фреймворки устроены внутри. А у вас какие основания клеймить ASP.NET? Неумение с ним работать? Незнание того, как его конвеер проинтегрирован с IIS7? Или просто незнакомство с предметом?

ВВ>Ну да, а сравнить ассемблер и ASP.NET — это видимо правила хорошего тона.
При чем здесь хороший тон?
Просто веб-сервер — это типичный пример высоконагруженного приложения. Математика в наши дни встречается редко; большинство десктопного софта в принципе никогда не сталкивается с ситуацией нехватки производительности.

S>>Еще раз медленно повторяю: пусть твои мужики воспроизведут на асме хотя бы один пример из самплов к Рихтеровской Power Threading Library. И посмотрим, кто кого порвёт по эффективности.
ВВ>Зачем?
Как зачем? Чтобы рассуждения "теоретически, самый быстрый код — это написанный вручную на ассемблере" перестали быть голословными. Пока что никаких доказательств этому в топике не прозвучало. Главный адвокат ручной сборки Дворкин продолжает удивлять примерами на С++.
А до тех порк, пока вы настаиваете на присутствии в рассуждениях "теоретического ассемблерщика", я настаиваю на соревновании его с "теоретическим компилятором".

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

ВВ>Или abstract gain он присутствует по определению, что бы мы не писали?
Нет, не по определению. Но он есть, и дается значительно дешевле, чем specialization gain, полученный вручную.

Поменьше эмоций, побольше мыслей.

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

ВВ>>И что мне от этого понимания? C# крут, потому что теоретически возможно написать супер-компилятор? Теоретически много чего возможно.
S>Совершенно верно. Я и говорю — теоретически можно и Http Handler на ассемблере написать.

Мне теоретический "суперкомплятор" неинтересен.

S>Лучший — это по результатам моего личного опыта. Сравнивали с JSP, ASP, PHP, Python. С наколеночными CGI на C и С++. Тесты проводили самые разнообразные. Кроме того, я немножко представляю себе, как все эти фреймворки устроены внутри. А у вас какие основания клеймить ASP.NET?

Опыт использования.
Вернее, давайте я поправлюсь — тот ASP.NET, который начинается и заканчивается на IHttpHandler/IHttpModule — это отличная штука. А вот все что сверху...

Развитие ASP.NETа — причем заметьте в понятие ASP.NET обычно вкладывается не технология "интеграции конвеера с IIS", а собственно web forms — это постепенное превращение его в чистой воды конструктор. Программирование мышкой. В свое время над Дельфи за этой посмеивались. То же самое в ASP.NET — как вы сказали? — высокотехнлогичность или как там? Неувязочка получается, нет?

Во-первых, сама по себе концепция веб-форм ущербна изначально. Это была попытка сделать программирование под веб похожим на windows forms — причем абсолютно непонятно зачем, учитывая принципиально разную модель работы приложений. Они даже св-ва к контролам типа BackColor и проч. поначалу прикрутили — чтобы на вин-формс было похоже. Тоже вот как бы уровень абстракции. А то, что там CSS-ы есть — это до них только потом дошло. В итоге сохраняем "уши" от ASP, aspCompat, мастерскую вставку, гениальный разбор самой ASPX страницы через регулярные выражения — но зато "где-то там" у нас "комплируемый" код. Ну это ладно.

Но что принпиально новое в нес ASP.NET? Чего добились создатели ASP.NET? Разделения логики и представления? Как бы не так. Ничем в сущности ASP.NET приложение не отличается от того же PHP. И там, и там одинаковая по большому счету свалка — только несколько иначе организованная. И там и там можно писать нормально, если уж очень захочется.

Далее. что у нас еще есть? Богатые библиотеки контролов? Берем ГридВью. Нет проблем! Бросили на форму, пару движений мышкой — все работает. Нужна двунаправленная сортировка, чтобы еще и в заголовка направление сортировки показывать? Без проблем, темплейт-column. Нужно чтобы выглядело по-красивее? Без проблем, еще пару движений мышкой. Ох, надо чтобы совсем-совсем по-красивее? Ой, а надо чтобы весь столбец, по к-му происходит сортировка подсвечивался? Ну что ж придется изменить рендеринг HTML — что ж делаем темплейт колонки (количества кода на странице начинает ох как расти). Хотите чтобы работать даже тривиальные функции ГридВью — не вздумайте отключить вью-стейт, ибо ни фига работать не будет. Ну ладно, вроде прикрутили, сделали. Завтра приходит клиент и говорит — о, а давайте это сделаем в виде вложенного грида, который по плюсику будет распахиваться, а эту и и эту колонку будем мержить когда такая-то информация выводится.
И вот смотрим мы — реально на кучу разметки и кода, которую пришлось — смотрим, и выбрасываем на фиг весь это грид, и переписываем все на XSLT. И — о чудо! — на XSLT кода получается даже меньше, а все наши фичи учтены. И выглядит аккуратнее. И работает быстрее.

И таких примеров можно много привести, и не только с контролами. Чуть-чуть сходишь с "рельс" — и все, приехали. Написав приложение на IHttpHandler/IHttpModule + XSLT, ты:
— получишь чистый код с нормальным разделением данных (XML), правил валидации (XSD) и представления (XSLT)
— получишь более производительный код
— и даже потратишь меньше времени (если приложение не хоум-пейдж)
Какой вывод после этого можно сделать о веб-формах? Но зато да, веб-формы это абстракция.

А ведь в описанной выше технике не используется ничего специфичного для АСП.НЕТ. Ее при желании можно реализовать и на ПХП.

S>Неумение с ним работать? Незнание того, как его конвеер проинтегрирован с IIS7? Или просто незнакомство с предметом?

Я так смотрю хамство — это нынче модный тренд на RSDN.

ВВ>>Ну да, а сравнить ассемблер и ASP.NET — это видимо правила хорошего тона.
S>При чем здесь хороший тон?
S>Просто веб-сервер — это типичный пример высоконагруженного приложения.

Еще раз повторяю — причем здесь вообще ASP.NET? Каким образом ASP.NET вообще возникает при разговоре об ассемблере?

Я в принципе понимаю, в чем ваша проблема. Не "ваша" конкретно, а вообще. Почему в принципе при разговоре об ассемблере возникает предложение написать на нем аналог ASP.NET приложения? Или мы исходим из принципа — все или ничего?
А правда в том, что есть задачи, в к-х abstraction не дает никаких gain-ов, одни penalty. И такие ситуации также реалистичны как и те, где введение уровня абстракции позволяет сделать приложение более производительным.

S>Математика в наши дни встречается редко; большинство десктопного софта в принципе никогда не сталкивается с ситуацией нехватки производительности.

Я этого никогда не отрицал.

S>Как зачем? Чтобы рассуждения "теоретически, самый быстрый код — это написанный вручную на ассемблере" перестали быть голословными.

Большинство рассуждений здесь голословны. Про суперкомпляторы, которые никто не видел в глаза, про производительность кода на C#.
Напишите с 0 на C#, без всяких managed direct x, 3D-движок, полностью дублирующий CryEngine 2 и при этом работающий по крайней мере с такой же скоростью?

S>Пока что никаких доказательств этому в топике не прозвучало. Главный адвокат ручной сборки Дворкин продолжает удивлять примерами на С++.
S>А до тех порк, пока вы настаиваете на присутствии в рассуждениях "теоретического ассемблерщика", я настаиваю на соревновании его с "теоретическим компилятором".

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

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

PD>Кстати, почему ты считаешь, что здесь именно колонка суммируется?

Потому, что так оно и есть. Я считаю суммы столбцов в матрице со 128000 столбцов и 1024 строками.
Т.к. мне нужно считать столбцы — я выбираю адекватное задаче представление матрицы. Она хранится транспонированной.

PD>Условие — расположение массива не менять!

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

С другой стороны, мне совершенно не понятно, какое отношение эти упражнения имеют к теме разговора и доказательству/опровержению тезиса о существовании abstraction gain?

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

S>Лучший — это по результатам моего личного опыта. Сравнивали с JSP, ASP, PHP, Python. С наколеночными CGI на C и С++.

JSP само по себе как бы не очень фреймворк. Это скорее только View, причем не единственно возможный и далеко не самый лучший. Аналог ASP.NET, как я понимаю, это что-нибудь вроде JSF/Tapestry/Wicket.

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

PD>Вернемся к бизнесу. Ну а если это не сайт и не АСУ (не к ночи будь помянута). О своих нынешних делах рассказывать не буду, а вот о том. что делал лет 10 назад — расскажу. А была это задача натягивания некоей текстуры на фотографию человека. Вот стоит он, одет в голубую рубашку, а еще ткань есть, клетчатая. И надо эту ткань на его рубашку наложить. Чтобы складки там остались, тени и т.д, но только чтобы он был не в голубом, а в клетчатом. Не помню, было ли там перемножение матриц, но, в общем, всяких алгоритмов там хватало.
PD>Это задача бизнеса ? Еще как — заказчик — некая фирма, которая эти рубашки шьет и хочет моделировать процесс — натянуть новый материал и посмотреть, что получится. Без человека — модели.

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

Ведь, согласись, помимо производительности еще и не менее важный "ресурс" — время называется

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

S>>Лучший — это по результатам моего личного опыта. Сравнивали с JSP, ASP, PHP, Python. С наколеночными CGI на C и С++. Тесты проводили самые разнообразные. Кроме того, я немножко представляю себе, как все эти фреймворки устроены внутри. А у вас какие основания клеймить ASP.NET?
ВВ>Опыт использования.
Судя по всему хреновый опыт. ASP.NET MVC видели?

ВВ>Вернее, давайте я поправлюсь — тот ASP.NET, который начинается и заканчивается на IHttpHandler/IHttpModule — это отличная штука. А вот все что сверху...
Расширяемая модель провайдеров? Dynamic Data?

ВВ>Развитие ASP.NETа — причем заметьте в понятие ASP.NET обычно вкладывается не технология "интеграции конвеера с IIS", а собственно web forms — это постепенное превращение его в чистой воды конструктор. Программирование мышкой. В свое время над Дельфи за этой посмеивались. То же самое в ASP.NET — как вы сказали? — высокотехнлогичность или как там? Неувязочка получается, нет?
Тем не менее на делфи делалась большая часть Enterprise софта в СНГ до появления C# 2.0


ВВ>Далее. что у нас еще есть? Богатые библиотеки контролов? Берем ГридВью. Нет проблем! Бросили на форму, пару движений мышкой — все работает. Нужна двунаправленная сортировка, чтобы еще и в заголовка направление сортировки показывать? Без проблем, темплейт-column. Нужно чтобы выглядело по-красивее? Без проблем, еще пару движений мышкой. Ох, надо чтобы совсем-совсем по-красивее? Ой, а надо чтобы весь столбец, по к-му происходит сортировка подсвечивался? Ну что ж придется изменить рендеринг HTML — что ж делаем темплейт колонки (количества кода на странице начинает ох как расти). Хотите чтобы работать даже тривиальные функции ГридВью — не вздумайте отключить вью-стейт, ибо ни фига работать не будет. Ну ладно, вроде прикрутили, сделали. Завтра приходит клиент и говорит — о, а давайте это сделаем в виде вложенного грида, который по плюсику будет распахиваться, а эту и и эту колонку будем мержить когда такая-то информация выводится.
Для сильно кастомной разметки используйте ListView.

ВВ>И вот смотрим мы — реально на кучу разметки и кода, которую пришлось — смотрим, и выбрасываем на фиг весь это грид, и переписываем все на XSLT. И — о чудо! — на XSLT кода получается даже меньше, а все наши фичи учтены. И выглядит аккуратнее. И работает быстрее.
ВВ>И таких примеров можно много привести, и не только с контролами. Чуть-чуть сходишь с "рельс" — и все, приехали. Написав приложение на IHttpHandler/IHttpModule + XSLT, ты:
ВВ>- получишь чистый код с нормальным разделением данных (XML), правил валидации (XSD) и представления (XSLT)
ВВ>- получишь более производительный код
ВВ>- и даже потратишь меньше времени (если приложение не хоум-пейдж)
ВВ>Какой вывод после этого можно сделать о веб-формах? Но зато да, веб-формы это абстракция.

Не могу удержаться. Код на в студию! XML+XSLT, повторяющий функциональность GridView: темплейты, пейджинг, сортировка, инплейс редактирование.

ВВ>А ведь в описанной выше технике не используется ничего специфичного для АСП.НЕТ. Ее при желании можно реализовать и на ПХП.
Компилируемое XSLT-преобразование есть в PHP?
Более того никто не мешает использовать ASP.NET MVC и XSLTViewEngine.

ВВ>Еще раз повторяю — причем здесь вообще ASP.NET? Каким образом ASP.NET вообще возникает при разговоре об ассемблере?
Ассемблер — это условно говоря самый низкий уровень абстракции, а ASP.NET — самый высокий.

ВВ>Люди, который пишут на ассемблере, есть. Задачи, который пока еще приходится реализовывать на самом низком уровне есть.
Вы уверены что эти люди напишут код, который всегда эффективнее кода на высокоуровневом языке?

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

G>Судя по всему хреновый опыт. ASP.NET MVC видели?

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

ВВ>>Вернее, давайте я поправлюсь — тот ASP.NET, который начинается и заканчивается на IHttpHandler/IHttpModule — это отличная штука. А вот все что сверху...
G>Расширяемая модель провайдеров? Dynamic Data?

Dynamic Data — для хоум-пейджей. Для хоум-пейджей и веб-форм подходит отлично.

ВВ>>Развитие ASP.NETа — причем заметьте в понятие ASP.NET обычно вкладывается не технология "интеграции конвеера с IIS", а собственно web forms — это постепенное превращение его в чистой воды конструктор. Программирование мышкой. В свое время над Дельфи за этой посмеивались. То же самое в ASP.NET — как вы сказали? — высокотехнлогичность или как там? Неувязочка получается, нет?
G>Тем не менее на делфи делалась большая часть Enterprise софта в СНГ до появления C# 2.0

А я против дельфи ничего не имею.

ВВ>>Далее. что у нас еще есть? Богатые библиотеки контролов? Берем ГридВью. Нет проблем! Бросили на форму, пару движений мышкой — все работает. Нужна двунаправленная сортировка, чтобы еще и в заголовка направление сортировки показывать? Без проблем, темплейт-column. Нужно чтобы выглядело по-красивее? Без проблем, еще пару движений мышкой. Ох, надо чтобы совсем-совсем по-красивее? Ой, а надо чтобы весь столбец, по к-му происходит сортировка подсвечивался? Ну что ж придется изменить рендеринг HTML — что ж делаем темплейт колонки (количества кода на странице начинает ох как расти). Хотите чтобы работать даже тривиальные функции ГридВью — не вздумайте отключить вью-стейт, ибо ни фига работать не будет. Ну ладно, вроде прикрутили, сделали. Завтра приходит клиент и говорит — о, а давайте это сделаем в виде вложенного грида, который по плюсику будет распахиваться, а эту и и эту колонку будем мержить когда такая-то информация выводится.
G>Для сильно кастомной разметки используйте ListView.

Угу, потратить кучу времени на лист-вью, а потом выкинуть и его тоже. Отличная перспектива.

G>Не могу удержаться. Код на в студию! XML+XSLT, повторяющий функциональность GridView: темплейты, пейджинг, сортировка, инплейс редактирование.

А вы попробуйте сами как-нибудь. Там все куда проще чем может показаться.

ВВ>>А ведь в описанной выше технике не используется ничего специфичного для АСП.НЕТ. Ее при желании можно реализовать и на ПХП.
G>Компилируемое XSLT-преобразование есть в PHP?

Это как-то влияет на ф-ность XSLT-процессора? В ПХП вообще нет ничего комплируемого. Что не мешает на ПХП написать приложение с лучшим перформансом чем на АСП.НЕТ+веб-форм.

G>Более того никто не мешает использовать ASP.NET MVC и XSLTViewEngine.
ВВ>>Еще раз повторяю — причем здесь вообще ASP.NET? Каким образом ASP.NET вообще возникает при разговоре об ассемблере?
G>Ассемблер — это условно говоря самый низкий уровень абстракции, а ASP.NET — самый высокий.

Поэтому надо сравнивать ассемблер с АСП.НЕТ? Логика железная!

ВВ>>Люди, который пишут на ассемблере, есть. Задачи, который пока еще приходится реализовывать на самом низком уровне есть.
G>Вы уверены что эти люди напишут код, который всегда эффективнее кода на высокоуровневом языке?

Я специально для тех в танке написал до этого — принцип "все или ничего" тут не действует.

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

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

G>>Судя по всему хреновый опыт. ASP.NET MVC видели?

ВВ>Давайте вы не будете судить о моем опыте, и я тоже не буду переходить на личности? Хамство не лучшее подспорье в беседе.
ВВ>И я писал конкретно о веб-формах, если вы не заметили.
А разговор был об ASP.NET.

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

ВВ>>>Вернее, давайте я поправлюсь — тот ASP.NET, который начинается и заканчивается на IHttpHandler/IHttpModule — это отличная штука. А вот все что сверху...
G>>Расширяемая модель провайдеров? Dynamic Data?
ВВ>Dynamic Data — для хоум-пейджей. Для хоум-пейджей и веб-форм подходит отлично.
Что для хоум-пейджей дает Dynamic Data, вы его вообще использовали?

G>>Для сильно кастомной разметки используйте ListView.
ВВ>Угу, потратить кучу времени на лист-вью, а потом выкинуть и его тоже. Отличная перспектива.
Ну если вы сразу планируете все выкинуть, то вам вообще ниче не поможет. В listView вы полностью контроллируете разметку, при этом остаются возможности пейдинга, сортировки, инплейс редактирвания. Пейджинг кстати на ListView можно сделать по GET запросу.

G>>Не могу удержаться. Код на в студию! XML+XSLT, повторяющий функциональность GridView: темплейты, пейджинг, сортировка, инплейс редактирование.

ВВ>А вы попробуйте сами как-нибудь. Там все куда проще чем может показаться.
Да я пробовал, но данные у меня не в XML гуляют туда-сюда.

ВВ>>>А ведь в описанной выше технике не используется ничего специфичного для АСП.НЕТ. Ее при желании можно реализовать и на ПХП.
G>>Компилируемое XSLT-преобразование есть в PHP?
ВВ>Это как-то влияет на ф-ность XSLT-процессора? В ПХП вообще нет ничего комплируемого. Что не мешает на ПХП написать приложение с лучшим перформансом чем на АСП.НЕТ+веб-форм.
Плохо написать можно на чем угодно. Это проблема писателей, а не технологии.

ВВ>Поэтому надо сравнивать ассемблер с АСП.НЕТ? Логика железная!
Да никто их не сравнивает. Просто хотят люди увидеть пример web страницы на ассемблере, по скорости сравнимой с ASP.NET. Это к вопросу об abstraction gain

Я сам очень недоволен тем, как работают веб-формы. Но сейчас webforms и dynamic data — наиболее удобный способ разработки базоморд, например админок сайта, мелки учетных приложеший итп. Для нормальных веб-приложений вебформы не подходят.

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

ВВ>>Давайте вы не будете судить о моем опыте, и я тоже не буду переходить на личности? Хамство не лучшее подспорье в беседе.
ВВ>>И я писал конкретно о веб-формах, если вы не заметили.
G>А разговор был об ASP.NET.

Разговор между кем и кем? То, что я писал — относилось к веб-формс. Каким боком тут поднимается MVC, который во-первых не зарелизен, а во-вторых представляет собой по большому счету замену веб-формс (что уже наводит на мысли как бы)?
"Классический" ASP.NET сейчас это все-таки веб-формс, так широко разрекламированный во всяких презентациях, где человек рисует страничку мышкой, раскидывает контролы, связывают их с датасурсами. Это не MVC, если говорить о паттерне, это анти-MVC.
Давайте я выделю жирным:

ASP.NET супер, Web Forms — отстой

Так претензии ко мне сняты?

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

А вы будете начинать новый проект прям на Бете?

ВВ>>>>Вернее, давайте я поправлюсь — тот ASP.NET, который начинается и заканчивается на IHttpHandler/IHttpModule — это отличная штука. А вот все что сверху...
G>>>Расширяемая модель провайдеров? Dynamic Data?
ВВ>>Dynamic Data — для хоум-пейджей. Для хоум-пейджей и веб-форм подходит отлично.
G>Что для хоум-пейджей дает Dynamic Data, вы его вообще использовали?

"Хоум-пейдж" это относительно простое приложение, с БД, которая вообще может создаваться с нуля и пр.
А как поможет Dynamic Data в приложении, где лет за пять до вас написали оракловую базу, где под сотню таблиц (про количество полей в этих таблицах я вообще промолчу)? А теперь еще представьте формы, работающие с этой БД. А еще данные из этой БД надо экспортировать в другую БД, которую разрабатывают вообще в другой строне и у нас execute right на несколько процедур всего. Это real world application.

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

G>>>Для сильно кастомной разметки используйте ListView.
ВВ>>Угу, потратить кучу времени на лист-вью, а потом выкинуть и его тоже. Отличная перспектива.
G>Ну если вы сразу планируете все выкинуть, то вам вообще ниче не поможет. В listView вы полностью контроллируете разметку, при этом остаются возможности пейдинга, сортировки, инплейс редактирвания. Пейджинг кстати на ListView можно сделать по GET запросу.

Веб контролы не масштабируются в принципе. Есть область функционала, где они работают хорошо — выходишь за ее пределы, и использование контрола становится невозможным. Приходится переделывать.
А если уж нужно тупо генерить HTML, то уж извини это гораздо проще делать через XSLT. Время по настройке пейджинга в том же дата-гриде аналогично времени на реализацию этого пейджинга в XSLT. Да, да, не надо делать круглые глаза. Если клиентский пейджинг — вставляешь 1 строку сортировку и 1 if. Ну да еще сам блок "пейджера" надо описать — при этом пейджер может выглядеть как угодно, и ты не будешь ломать голову как бы настроить его также как на mock-up нарисовано, используя все три св-ва в датагриде.
Опять-таки как будет работать пейджит — через GET или не через GET — как хочешь так и сделай. Сортировка через GET — две строчки кода фактически. Причем это масштабируется блин.

G>>>Не могу удержаться. Код на в студию! XML+XSLT, повторяющий функциональность GridView: темплейты, пейджинг, сортировка, инплейс редактирование.
ВВ>>А вы попробуйте сами как-нибудь. Там все куда проще чем может показаться.
G>Да я пробовал, но данные у меня не в XML гуляют туда-сюда.

Пользовательский XPathNavigator поможет. Писали еще лет пять назад.

ВВ>>Это как-то влияет на ф-ность XSLT-процессора? В ПХП вообще нет ничего комплируемого. Что не мешает на ПХП написать приложение с лучшим перформансом чем на АСП.НЕТ+веб-форм.
G>Плохо написать можно на чем угодно. Это проблема писателей, а не технологии.

Технология, особенно "крутая" современная технология должна хотя бы поощрят писать хорошо. Лучше — давать минимальные возможности писать плохо. Web Forms этого не делает.

Ну веб-форм реально хреновая штука. Мне нравятся веб-приложения, нравится работать с HTTP-протоколом, нравится в .NET реализован низкий уровень работы с HTTP, но даже сама изначальная концепция web forms — это же просто неправильно. И реальные (а не картинках) большие приложения на АСП.НЕТ приводят к тому, что уже рвотный рефлекс на все это вырабатывается.
И нас этим кормят уже почти семь лет.

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

ВВ>>Поэтому надо сравнивать ассемблер с АСП.НЕТ? Логика железная!
G>Да никто их не сравнивает. Просто хотят люди увидеть пример web страницы на ассемблере, по скорости сравнимой с ASP.NET. Это к вопросу об abstraction gain

А я хочу увидеть 3Д-движок, написанный с использование АСП-НЕТ разметки. Может, нам вместе с доктору записаться?

G>Я сам очень недоволен тем, как работают веб-формы. Но сейчас webforms и dynamic data — наиболее удобный способ разработки базоморд, например админок сайта, мелки учетных приложеший итп. Для нормальных веб-приложений вебформы не подходят.


Как думаешь, на момент презентации, скажем, ASP.NET 2.0 это было официальной позицией MS?

А ведь веб-формс — просто уровень абстракции над прямой работой с HTTP. И отличный пример того, как этот уровень абстракции для "нормальных веб-приложений" может не иметь никакого gain, а только penalty.

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


ВВ>А вы будете начинать новый проект прям на Бете?
Я уже сделал пару проектов на ASP.NET MVC(еще Preview версии), на бете один сейчас в разработке.

ВВ>"Хоум-пейдж" это относительно простое приложение, с БД, которая вообще может создаваться с нуля и пр.
ВВ>А как поможет Dynamic Data в приложении, где лет за пять до вас написали оракловую базу, где под сотню таблиц (про количество полей в этих таблицах я вообще промолчу)? А теперь еще представьте формы, работающие с этой БД. А еще данные из этой БД надо экспортировать в другую БД, которую разрабатывают вообще в другой строне и у нас execute right на несколько процедур всего. Это real world application.
Это вообще проблемы другого уровня. Сделйте на EF модель поверх того что вам доступно и сможете пользоваться Dynamic Data.

ВВ>А динамик дата — "украшательство", которое где-то подойдет, а где-то в принципе не подойдет. Как и linq2sql, впрочем. Тоже кстати еще одна красивая абстракция. Только вот хинты по-прежнему в запросах прописывать надо.
Про ORMы был флейм в другой теме.

ВВ>Веб контролы не масштабируются в принципе. Есть область функционала, где они работают хорошо — выходишь за ее пределы, и использование контрола становится невозможным. Приходится переделывать.
В этом и есть суть контрола.

ВВ>А если уж нужно тупо генерить HTML, то уж извини это гораздо проще делать через XSLT.
Я бы предпочел возможность выбирать на чем тупо рендерить HTML без изменений в остальной программе.

ВВ>Время по настройке пейджинга в том же дата-гриде аналогично времени на реализацию этого пейджинга в XSLT. Да, да, не надо делать круглые глаза. Если клиентский пейджинг — вставляешь 1 строку сортировку и 1 if. Ну да еще сам блок "пейджера" надо описать — при этом пейджер может выглядеть как угодно, и ты не будешь ломать голову как бы настроить его также как на mock-up нарисовано, используя все три св-ва в датагриде.
ВВ>Опять-таки как будет работать пейджит — через GET или не через GET — как хочешь так и сделай. Сортировка через GET — две строчки кода фактически. Причем это масштабируется блин.
А инплейсное редактирование?

ВВ>Технология, особенно "крутая" современная технология должна хотя бы поощрят писать хорошо. Лучше — давать минимальные возможности писать плохо. Web Forms этого не делает.
Это сильно зависит от того что такое хорошо. Иногда "хорошо" значит написать быстро, WebForms это обеспечивает. Для "правильного" писания веб-приложений вебформы не подходят.

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

G>>Я сам очень недоволен тем, как работают веб-формы. Но сейчас webforms и dynamic data — наиболее удобный способ разработки базоморд, например админок сайта, мелки учетных приложеший итп. Для нормальных веб-приложений вебформы не подходят.
ВВ>
ВВ>Как думаешь, на момент презентации, скажем, ASP.NET 2.0 это было официальной позицией MS?
Архитекторы ASP.NET неправльно представляли себе web.

ВВ>А ведь веб-формс — просто уровень абстракции над прямой работой с HTTP.
Не, HttpHandler — уровень абстракции над выводом в stdout для формирования страницы. А вебформы находятся на 3-4 условных уровня выше.

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

ВВ>>А вы будете начинать новый проект прям на Бете?
G>Я уже сделал пару проектов на ASP.NET MVC(еще Preview версии), на бете один сейчас в разработке.

А я не могу "продать", скажем, крупному мобильному оператору проект на непонятно какой бете, которая не поддерживается.

ВВ>>"Хоум-пейдж" это относительно простое приложение, с БД, которая вообще может создаваться с нуля и пр.
ВВ>>А как поможет Dynamic Data в приложении, где лет за пять до вас написали оракловую базу, где под сотню таблиц (про количество полей в этих таблицах я вообще промолчу)? А теперь еще представьте формы, работающие с этой БД. А еще данные из этой БД надо экспортировать в другую БД, которую разрабатывают вообще в другой строне и у нас execute right на несколько процедур всего. Это real world application.
G>Это вообще проблемы другого уровня. Сделйте на EF модель поверх того что вам доступно и сможете пользоваться Dynamic Data.

Да того, того уровня. Представьте как будет происходить работа с такой базой — джойн там по парочке таблиц уже трагедия. Там не до Linq.

ВВ>>Время по настройке пейджинга в том же дата-гриде аналогично времени на реализацию этого пейджинга в XSLT. Да, да, не надо делать круглые глаза. Если клиентский пейджинг — вставляешь 1 строку сортировку и 1 if. Ну да еще сам блок "пейджера" надо описать — при этом пейджер может выглядеть как угодно, и ты не будешь ломать голову как бы настроить его также как на mock-up нарисовано, используя все три св-ва в датагриде.
ВВ>>Опять-таки как будет работать пейджит — через GET или не через GET — как хочешь так и сделай. Сортировка через GET — две строчки кода фактически. Причем это масштабируется блин.
G>А инплейсное редактирование?

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

А если например нужно *все* строки по умолчанию показывать в режиме редактирования? Вот нехочется людям каждый раз "кликать" на эдит. А еще хочется например поменять значение в столбце Х и чтобы во всех столбцах с *аналогичными* значениями тоже значение поменялось? На XSLT я эту фичу прикручу, веб-контрол — в recycle bin.

ВВ>>Технология, особенно "крутая" современная технология должна хотя бы поощрят писать хорошо. Лучше — давать минимальные возможности писать плохо. Web Forms этого не делает.
G>Это сильно зависит от того что такое хорошо. Иногда "хорошо" значит написать быстро, WebForms это обеспечивает. Для "правильного" писания веб-приложений вебформы не подходят.

"Хорошо" — это чтобы в принципе работало, не глючило, чтобы в срок и чтобы деньги за проект заплатили, а я свои бонусы за проект получил. Это хорошо. Остальное, если честно, не [censored].
А таким понятием как "маленькое веб-приложение" я давно по работе не сталкивался. Везде сплошные корпоративные интранеты, а там рулят портальные решения, а что у нас у МС в качестве портального решения? MOSS? О, нет, не "открывайте", я же только что поел!

ВВ>>А Шарепоинт вы видели, который на основе веб-форм построен? И во что там мастер-пейджи превращаются, когда нужно их дизайн перетачивать под нарисованные картинки. Причем иначе и не сделаешь фактически. Пусть вот эти клоуны сначала туда MVC прикрутят.
G>Мне слава богу не доводилось таким заниматься. Да и шарепоинт не для этого нужен.

А для чего нужен MOSS? Поведайте нам. А лучше парням из МС которые продают его кому ни попадя, как отличное портальное решение. А потом интеграторы по программе парнер-шипа с ним [censored].

ВВ>>Как думаешь, на момент презентации, скажем, ASP.NET 2.0 это было официальной позицией MS?
G>Архитекторы ASP.NET неправльно представляли себе web.

И о чем тогда спорим, казалось бы?

ВВ>>А ведь веб-формс — просто уровень абстракции над прямой работой с HTTP.
G>Не, HttpHandler — уровень абстракции над выводом в stdout для формирования страницы. А вебформы находятся на 3-4 условных уровня выше.

Ну как сказать... class Page : IHttpHandler. Впрочем, не суть.

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

ВВ>Да того, того уровня. Представьте как будет происходить работа с такой базой — джойн там по парочке таблиц уже трагедия. Там не до Linq.
Не делайте джоины.

ВВ>Ну а какие проблемы? Нажали на кнопочку, перерисовали грид через XSLT — для строк соотв. используются просто другой XSLT-шаблон — нажали на кнопочку сохранить — функция на джаваскрипте отсылает данные на сервер — порядка 10 строк кода — грид перерисовывается.
Ну если потом все эти мелкие функции, ифы и проче собрать получится дофига кода.
Я такоеже мнение от программиста на ПХП слышал, типа все лего, там 10 строчек, тут 5... В итоге 2 недели делал, так и не сделал.

ВВ>А если например нужно *все* строки по умолчанию показывать в режиме редактирования? Вот нехочется людям каждый раз "кликать" на эдит.
Details\Form View?
Ну или совсем изврат в виде Repeater+Grid\ListView

ВВ>А еще хочется например поменять значение в столбце Х и чтобы во всех столбцах с *аналогичными* значениями тоже значение поменялось? На XSLT я эту фичу прикручу, веб-контрол — в recycle bin.
Не понял что надо, но понял что стандартные контролы на это не рассчитаны. Ну в таком случае ниче не поможет. Вы же не ругаете библиотеку контролов для десктомных приложений что там нельзя что-то сделать.

ВВ>"Хорошо" — это чтобы в принципе работало, не глючило, чтобы в срок и чтобы деньги за проект заплатили, а я свои бонусы за проект получил. Это хорошо. Остальное, если честно, не [censored].
На самом деле важно только выделенное.

ВВ>А для чего нужен MOSS? Поведайте нам. А лучше парням из МС которые продают его кому ни попадя, как отличное портальное решение. А потом интеграторы по программе парнер-шипа с ним [censored].
Я с ним только с точки зрения документооборота сталкивался.Интерфейс ковырять не приходилось.

ВВ>>>Как думаешь, на момент презентации, скажем, ASP.NET 2.0 это было официальной позицией MS?
G>>Архитекторы ASP.NET неправльно представляли себе web.
ВВ>И о чем тогда спорим, казалось бы?
О том что web-формы можно использовать... но далеко не везде.

ВВ>>>А ведь веб-формс — просто уровень абстракции над прямой работой с HTTP.
G>>Не, HttpHandler — уровень абстракции над выводом в stdout для формирования страницы. А вебформы находятся на 3-4 условных уровня выше.
ВВ>Ну как сказать... class Page : IHttpHandler. Впрочем, не суть.
Это значит что страница сама может обрабатывать запрос. Абстракция заключается в том как она его обрабатывает.

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

ВВ>>Да того, того уровня. Представьте как будет происходить работа с такой базой — джойн там по парочке таблиц уже трагедия. Там не до Linq.
G>Не делайте джоины.

А ну ради бога, если dynamic data и linq у вас подходит для всех случаев жизни, то я вас переубеждать не собираюсь.

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

А его еще больше с веб-контролами получается, в том-то все и дело.

ВВ>>А если например нужно *все* строки по умолчанию показывать в режиме редактирования? Вот нехочется людям каждый раз "кликать" на эдит.
G>Details\Form View?
G>Ну или совсем изврат в виде Repeater+Grid\ListView
ВВ>>А еще хочется например поменять значение в столбце Х и чтобы во всех столбцах с *аналогичными* значениями тоже значение поменялось? На XSLT я эту фичу прикручу, веб-контрол — в recycle bin.
G>Не понял что надо, но понял что стандартные контролы на это не рассчитаны. Ну в таком случае ниче не поможет. Вы же не ругаете библиотеку контролов для десктомных приложений что там нельзя что-то сделать.

А мне вот неизвестно изначально, что клиент захочет. Я хочу чтобы технология была гибкой и позволяла легко вносить изменения, если они требуются. Или мне под каждый requirement все с нуля переписывать?
Как объяснить бизнесу, что реализация фичи Х занимает 3 часа, а для фичи У надо все на фиг переписать? С т.з. клиента это совершенно нелогично.
Я уж не говорю о производительности всего этого добра, которое по малейшему чиху тянет вью-стейт, а если его отключить, то контролы теряют все свои замечательные фишки.

Вот кстати в вин-формах ситуация значительно лучше. Я там контрол могу хоть раком поставить. При этом "отрисовать все самому" мне в голову придет в последнюю очередь. Есть конечно ограничения, но в значительно меньшей степени.

ВВ>>"Хорошо" — это чтобы в принципе работало, не глючило, чтобы в срок и чтобы деньги за проект заплатили, а я свои бонусы за проект получил. Это хорошо. Остальное, если честно, не [censored].
G>На самом деле важно только выделенное.

Да, ты знаешь, мне важно, чтобы компания на проекте заработала.

ВВ>>А для чего нужен MOSS? Поведайте нам. А лучше парням из МС которые продают его кому ни попадя, как отличное портальное решение. А потом интеграторы по программе парнер-шипа с ним [censored].
G>Я с ним только с точки зрения документооборота сталкивался.Интерфейс ковырять не приходилось.

Очень странно. Потому что шарепоинт решений для документооборота не предлагает.

ВВ>>>>Как думаешь, на момент презентации, скажем, ASP.NET 2.0 это было официальной позицией MS?
G>>>Архитекторы ASP.NET неправльно представляли себе web.
ВВ>>И о чем тогда спорим, казалось бы?
G>О том что web-формы можно использовать... но далеко не везде.

А я с этим спорю? Да, для хоум-пейджей отличное решение. Но не более.

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

K>С другой стороны, мне совершенно не понятно, какое отношение эти упражнения имеют к теме разговора и доказательству/опровержению тезиса о существовании abstraction gain?

В этом и суть

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

PD>Вот тебе пример. Делал как-то приложение на C#. Ничего особенного, форма с табами, на них всякие листбоксы и т.д. За сценой никаких больших объектов (потом при работе они появятся, но до первого запроса их нет). 17 Мб вся эта прелесть занимает. Уверен, что больше 4-5 Мб она занимать не должна — на MFC. На чистом Win API — думаю, в 2-3 Мб уложился бы, но на это точно много моего времени уйдет.

Хм, кажется вопрос с отжиранием памяти дотнетом не раз обсуждался тут...

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

ВВ>А мне вот неизвестно изначально, что клиент захочет. Я хочу чтобы технология была гибкой и позволяла легко вносить изменения, если они требуются. Или мне под каждый requirement все с нуля переписывать?

Зачем с нуля? Купить контролы сторонних производителей.

ВВ>Как объяснить бизнесу, что реализация фичи Х занимает 3 часа, а для фичи У надо все на фиг переписать? С т.з. клиента это совершенно нелогично.

А вот так и приходится. Постоянно. Жизнь у айтишников такая.

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

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

В Windows Forms точно такая же проблема. И ограничения там мешают в неменьшей степени. Самой гибкой "технологией" оказалась бы "попиксельный рендеринг с помощью XSLT".