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

M>>>>>Если существуют методологии позволяющие очень сильно повысить читабельность, уменьшить к-во, улучшить сопровождение и т.п. Я бы очень хотел об этом подробнее узнать.
IT>>>>См. FP.
M>>>Я читал предыдущий пост пере тем как ответить.
IT>>Тогда что именно не понятно?
M>Я не говорил что мне что то непонятно.

Если всё понятно, то о чём тогда хочется подробнее узнать?

M>Понятия не имею с чего ты взял? на мой взгляд ничего революционного там нет? Я имел ввиду написаноого в революцыонном стиле (FP например) из подобного рода проектов не встречал.

Почему тогда от FP хочется именно чего-то революционного?

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

ВВ>Проблема тех же контролов в том, что с одной стороны это "шаблоны", уровень некоторой абстракции над HTML

Контролы и HTML связаны лишь тем, что контролы занимаются рендерингом HTML. Этим всё равно должен кто-то заниматься. У тебя есть притензии к контролам, что они плохо рендерят HTML?

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

Пиши свои контролы, в чём проблема?

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

ViewState — это как раз и есть затычка, призванная упростить работу с состоянием. Но получается это по-любому хреново из за того, что состоянию распределённость противопоказана.

ВВ>А AJAX тоже не панацея. Особенно то, как это сделано в ASP.NET.

UpdatePanel — это обманка. Проблему состояния такой AJAX не решает никак.

ВВ>ИМХО дело не в технологии "передачи" состояния — ибо все равно ты его будешь передавать на сервер в конечно счете. Проблема в том, что построив "абстракцию" над HTTP, внутри АСП.НЕТ все те же формы, поля и пр. — т.е. методы работы с данными самые что ни на есть древние.

Ты явно путаешь HTTP с чем-то другим. Формы не являются надстройкой над HTTP. HTTP — это всего лишь протокол передачи данных.

ВВ>Интереснее было бы, мне кажется, структировать сам формат состояния да и вообще данные, которые гоняются туда сюда. Например, чтобы это была не форма вида key=value&k2=value2..., а XML документ, который в свою очередь можно всегда проверить по XML-схеме, всегда можно показать используя различные стайлшиты (XSLT), а уж технология передачи — это мне кажется дело вторичное.

Повторяю ещё раз. Состоянию противопоказан распределённость. Если попытаться распределить состояние между UI (WPF/WinForms) приложением и сервером, то ты мгновено получишь теже самы проблемы, с точностью до изобретения ViewState. Это не проблема конкретно WebForms, это проблема подхода.

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

C>Если поле ввода, то хранится как простой String в модели страницы. Поля ввода синхронизируются при совершении действия, требующего вызов серверного события. Т.е. у тебя форма с 10 полями, ты их как-то редактируешь на клиенте, а когда нажимаешь кнопку "OK" изменённые поля уходят на сервер вместе с событием "кнопка нажата". На сервере изменения вливаются в модель, а потом вызывается обработчик.

C>Если повесить обработчик на событие "фокус потерян", то синхронизироваться будет после потери фокуса (для валидации, например).

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

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

C>>Если повесить обработчик на событие "фокус потерян", то синхронизироваться будет после потери фокуса (для валидации, например).
IT>WebForms работают по такой же схеме. Проблемы начинаются при усложнении взаимодействия с пользователем и необходимости в использовании нестандартных для данной технологии средств.
Проблемы везде бывают. Просто это было возражение про то, что на сервере состояние в принципе хранить нельзя.

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

IT>Контролы и HTML связаны лишь тем, что контролы занимаются рендерингом HTML. Этим всё равно должен кто-то заниматься. У тебя есть притензии к контролам, что они плохо рендерят HTML?

У меня есть претензии к контролам вообще, как к сущности. Мне кажется им не место в веб-приложении вообще, самой концепции контролов в принципе. В идеале должен быть некий мета-язык, которые позволит описывать структуру страниц.
Вот есть такая отличная штука — XForms называется. Наверняка ведь слышал. Почему бы МС его не реализовать?

ВВ>>Потом ты вот говоришь, что тебе не нравится как организована работа с состоянием. А ведь viewstate — одна из основных фишек контролов. Причем он всегда или есть или нет. Т.е. я не могу его отключить частично, если мне нет нужны дублировать данные контрола и перегружать страницу.
IT>ViewState — это как раз и есть затычка, призванная упростить работу с состоянием. Но получается это по-любому хреново из за того, что состоянию распределённость противопоказана.

Как я и написал в самом начале состояние не может не быть распределенным. Да, это плохо. Но другого не дано.

ВВ>>А AJAX тоже не панацея. Особенно то, как это сделано в ASP.NET.
IT>UpdatePanel — это обманка. Проблему состояния такой AJAX не решает никак.

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

ВВ>>ИМХО дело не в технологии "передачи" состояния — ибо все равно ты его будешь передавать на сервер в конечно счете. Проблема в том, что построив "абстракцию" над HTTP, внутри АСП.НЕТ все те же формы, поля и пр. — т.е. методы работы с данными самые что ни на есть древние.
IT>Ты явно путаешь HTTP с чем-то другим. Формы не являются надстройкой над HTTP. HTTP — это всего лишь протокол передачи данных.

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

IT>Повторяю ещё раз. Состоянию противопоказан распределённость. Если попытаться распределить состояние между UI (WPF/WinForms) приложением и сервером, то ты мгновено получишь теже самы проблемы, с точностью до изобретения ViewState. Это не проблема конкретно WebForms, это проблема подхода.

А мне кажется проблема в том, как хранится состояние. Оно неорганизовано, представляет собой "кашу", которую в случае с АСП.НЕТ обрабатывается на уровне каждого отдельного контрола и рендеринге страницы снова собирается в "кашу". Мне кажется, если состояние описывать более структурировано, то это поможет решить проблемы. А с распределенностью ничего сделать не получится.

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

ВВ>Опыт использования.
ВВ>Вернее, давайте я поправлюсь — тот ASP.NET, который начинается и заканчивается на IHttpHandler/IHttpModule — это отличная штука.
Совершенно верно. И далеко не всё, что сверху, так плохо как кажется.
ВВ>Развитие ASP.NETа — причем заметьте в понятие ASP.NET обычно вкладывается не технология "интеграции конвеера с IIS", а собственно web forms — это постепенное превращение его в чистой воды конструктор.
Мне всё равно, что именно вкладывается в это понятие обычно. Точно так же, как и то, что среднестатистический программист обычно только ухудшает код при первых попытках вставить что-то на ассемблере.
ВВ>Программирование мышкой. В свое время над Дельфи за этой посмеивались. То же самое в ASP.NET — как вы сказали? — высокотехнлогичность или как там? Неувязочка получается, нет?
Программирование мышкой здесь ни при чем. Можно хоть подмышкой программировать, вопрос в том, какие возможности дает фреймворк, какой объем кода при этом нужно писать вручную, и какая при этом получается эффективность конечного решения.

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

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


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

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

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

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

ВВ>А правда в том, что есть задачи, в к-х abstraction не дает никаких gain-ов, одни penalty. И такие ситуации также реалистичны как и те, где введение уровня абстракции позволяет сделать приложение более производительным.
С этим никто и не спорил. На всякий случай напомню, что местная притча во языцех — Павел Дворкин, с юношеским задором объявлял повышение производительности за счет введения уровней абстракции нереалистичными.
S>>Как зачем? Чтобы рассуждения "теоретически, самый быстрый код — это написанный вручную на ассемблере" перестали быть голословными.
ВВ>Большинство рассуждений здесь голословны. Про суперкомпляторы, которые никто не видел в глаза
Идем по ссылке, смотрим на суперкомпилятор джавы. В чем проблема?

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

Попробую зайти с другой стороны.

Почему по твоему мнению , серезные приложения которые я перечислял FFMPEG — JASPER написанны без использования FP ? на традиционных C/C++. ?

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

M>Почему по твоему мнению , серезные приложения которые я перечислял FFMPEG — JASPER написанны без использования FP ? на традиционных C/C++. ?

А серьезное приложение Autocad написано с использованием FP. Какие из этого мы можем сделать выводы?

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

M>Вы уверенны что это эквивалентные программы , по скорости выполнения ? по сложности ? по потреблению памяти ?

Ты дальше читал?

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

M>Попробую зайти с другой стороны.

M>Почему по твоему мнению , серезные приложения которые я перечислял FFMPEG — JASPER написанны без использования FP ? на традиционных C/C++. ?

Как думаешь почему основная масса серъезных (и не очень серъезных тоже) приложений до года примерно 98 писалась в большинстве своем на си без использования ООП ?

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

M>Почему по твоему мнению , серезные приложения которые я перечислял FFMPEG — JASPER написанны без использования FP ? на традиционных C/C++. ?

Если бы они были написаны с использованием FP, то они были бы ещё серьёзней.

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

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

Как уже сказали FP и связаные с ним вкусности и сахар.

M>Но я оцениваю вероятность такой ситуации близкой к нулю , потому что не встречал написанных революционно проектв типа FFMPEG или openCV или декодер jpeg2000.

Пока просто нет нужной массовости, но ситуация уже меняется, в общем ждем релиза F# и доведение до ума Scala скорее всего на них появятся первые серъезные приложения. Хотя последние версии Haskell'а тоже радуют.

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

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

M>>Почему по твоему мнению , серезные приложения которые я перечислял FFMPEG — JASPER написанны без использования FP ? на традиционных C/C++. ?

Pzz>А серьезное приложение Autocad написано с использованием FP. Какие из этого мы можем сделать выводы?

Исходников автокада у меня нет , я не могу оценить как и где там использовалось FP. Боюсь что аналогия не очень уместна , предполагаю что автокад стстоит и большого числа компонентов с различными требованиями.

Например критичные к эфективности компоненты могут быть написанны на C++, а высокоуровневая логика на языке с элементами FP.

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

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

M>>Попробую зайти с другой стороны.

M>>Почему по твоему мнению , серезные приложения которые я перечислял FFMPEG — JASPER написанны без использования FP ? на традиционных C/C++. ?

FR>Как думаешь почему основная масса серъезных (и не очень серъезных тоже) приложений до года примерно 98 писалась в большинстве своем на си без использования ООП ?

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

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

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

M>>Почему по твоему мнению , серезные приложения которые я перечислял FFMPEG — JASPER написанны без использования FP ? на традиционных C/C++. ?

IT>Если бы они были написаны с использованием FP, то они были бы ещё серьёзней.

Попробую еще раз , а почему они не написанны с использованием FP ?

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

FR>Пока просто нет нужной массовости, но ситуация уже меняется, в общем ждем релиза F# и доведение до ума Scala скорее всего на них появятся первые серъезные приложения. Хотя последние версии Haskell'а тоже радуют.

А я считаю что дело не в массовости , потому что FFMPEG ядро делают несколько человек. Я уверен, что если бы использование FP дало бы хоть 5% к производительности программы ядро бы уже переписали.

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

M>Например критичные к эфективности компоненты могут быть написанны на C++, а высокоуровневая логика на языке с элементами FP.

По моему это вполне нормальная практика. Таким образом пишут приложения например на очень даже не шустром питоне, при этом эффективность разработки существенно выше чем на чистом C++.

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

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

M>>Например критичные к эфективности компоненты могут быть написанны на C++, а высокоуровневая логика на языке с элементами FP.

FR>По моему это вполне нормальная практика. Таким образом пишут приложения например на очень даже не шустром питоне, при этом эффективность разработки существенно выше чем на чистом C++.

Ну да , я полностью согласен. А почему ВСЕ приложение не пишется нв питоне?

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

FR>>Как думаешь почему основная масса серъезных (и не очень серъезных тоже) приложений до года примерно 98 писалась в большинстве своем на си без использования ООП ?

M>Вероятно предпочтение языку давалось исходя из функциональных требований к программе ?

Нет чаще исходя из доступности разработчиков владеющих нужной технологией.

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


M>>>Почему по твоему мнению , серезные приложения которые я перечислял FFMPEG — JASPER написанны без использования FP ? на традиционных C/C++. ?

IT>>Если бы они были написаны с использованием FP, то они были бы ещё серьёзней.

M>Попробую еще раз , а почему они не написанны с использованием FP ?

Потому что для подобных вещей важна не эффективность разработки а эффективность работы готового кода. Пока FP компиляторы не достигли уровня хороших C++ компиляторов.