Здравствуйте, Plutonia Experiment, Вы писали:
PE>Здравствуйте, VladD2, Вы писали:
PE>>>Лучше 50% тормозов, чем сотня коллекций copy-paste-replace. VD>>copy-paste-replace то зачем? Ну, да тебе решать.
PE>Для типизированых коллекций. Подскажи способ лучше.
Сколько ж можно? Тебе говорят, что генераторы кода для коллекций использовать надо. Ими весь Инет завален.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>Почему?
PE>На C# можно сделать так, но гораздо удобнее сделать это в специаизированом языке.
Не, я с тебя писяюсь . Почему не сделали спец. язык? Потому что слишком долго его делать. А почему не воспользоваться XML+C#? Потому что свой удобнее.
AVK>>Вот и построй его на основе XML.
PE>На основе XML неудобно.
Не знаю, не знаю. Вон ASP.NET показывает что очень даже ничего.
PE> Я думаю, что это может быть нечто вроде С-подобного языка такого плана.
С-подобный язык плохо подходит для декларативного описания, а правильный генератор на 90% управляется декларативно.
PE>XML сгодится на первое время. Вся проблема в том, что модель слишком сложная.
Любая сложная модель может быть упрощена за счет дополнительных абстракций. Я конечно ничего не могу сказать по поводу твоей задачки, но все подобные проблемы что мне встречались в итоге решались довольно просто, нужно было лишь тщательно разработать описательную модель.
Здравствуйте, AndrewVK, Вы писали:
AVK>Не, я с тебя писяюсь . Почему не сделали спец. язык? Потому что слишком долго его делать. А почему не воспользоваться XML+C#? Потому что свой удобнее.
Ой как умно, господин модератор. Перечитай ветку и не дури мне головы.
Предложи свой вариант на XML+С#, чтобы было столько же кода и столько же функциональности.
PE>>На основе XML неудобно. AVK>Не знаю, не знаю. Вон ASP.NET показывает что очень даже ничего.
Почему бы тебе на XML и программы тогда не писать ? Ты никогда не думал, что вместо C# можно и так писать
AVK>С-подобный язык плохо подходит для декларативного описания, а правильный генератор на 90% управляется декларативно.
Очень неплохо подходит. Смотри в IDL. Но это не единсвенное решение.
AVK>Любая сложная модель может быть упрощена за счет дополнительных абстракций. Я конечно ничего не могу сказать по поводу твоей задачки, но все подобные проблемы что мне встречались в итоге решались довольно просто, нужно было лишь тщательно разработать описательную модель.
Упрощено все, что можно упростить. Нельзя сделать просто, если нужен и мастшаб большой и высокая степень детализации.
Здравствуйте, VladD2, Вы писали:
PE>>>>Лучше 50% тормозов, чем сотня коллекций copy-paste-replace. VD>>>copy-paste-replace то зачем? Ну, да тебе решать.
PE>>Для типизированых коллекций. Подскажи способ лучше.
VD>Сколько ж можно? Тебе говорят, что генераторы кода для коллекций использовать надо. Ими весь Инет завален.
Я уже сто раз говорил про это — неудобно. Генерировать лучше текст. Туда и бряк можно поставить легко и какую колекцию подменить, чтобы отладку упростить , и новому человеку проще дебажить. Много плюсов.
Создание такой коллекции — минутное дело.
Я не виду никаких преимуществ, кроме меньшего размера теста программы.
Здравствуйте, AndrewVK, Вы писали:
AVK>Не знаю, не знаю. Вон ASP.NET показывает что очень даже ничего.
У нас есть кой какой опыт в этом. Один объект описать на XML(статическая часть модели хранится в БД) — это примерно 3 кб текста. Это касается только загрузки.
При чем текст не читабельный и слишком плотный. Могу послать кусочек, если интересно, но в форум не могу постить.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Ой как умно, господин модератор. Перечитай ветку и не дури мне головы.
PE>>>На основе XML неудобно. AVK>>Не знаю, не знаю. Вон ASP.NET показывает что очень даже ничего.
PE>Почему бы тебе на XML и программы тогда не писать?
Потому что программы содержат в основном императивные инструкции.
AVK>>С-подобный язык плохо подходит для декларативного описания, а правильный генератор на 90% управляется декларативно.
PE>Очень неплохо подходит.
Это тебе кажется удобнее, потому что ты на плюсах пишешь. Только ты то жаловался на то что те кто это должен писать — непрограммисты. А для них куда как проще декларативный стиль задания.
PE> Смотри в IDL.
Вот смотрел, потому и говорю. WSDL удобнее, более масштабируемо и мощнее.
PE>Нельзя сделать просто, если нужен и мастшаб большой и высокая степень детализации.
Здравствуйте, AndrewVK, Вы писали:
PE>>Почему бы тебе на XML и программы тогда не писать? AVK>Потому что программы содержат в основном императивные инструкции.
Вот в чем дело. Взаимодействие объектов придется частично на этом же языке описывать.
PE>>Очень неплохо подходит.
AVK>Это тебе кажется удобнее, потому что ты на плюсах пишешь. Только ты то жаловался на то что те кто это должен писать — непрограммисты. А для них куда как проще декларативный стиль задания.
Проще, но не XML. XML сгодится в качестве промежуточного. Генератор должен XML примнимать, а вот человеку с XML работать не нужно. Слишком много текста и структура плохая.
AVK>Вот смотрел, потому и говорю. WSDL удобнее, более масштабируемо и мощнее.
Ничего тут не удобнее. Если один раз написать и забыть, то можно и XML,WSDL и все, что хочешь юзать.
А если ты постоянно будешь работать с языком, то XML тут не помощник.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>Потому что программы содержат в основном императивные инструкции.
PE>Вот в чем дело. Взаимодействие объектов придется частично на этом же языке описывать.
Взаимодействие тоже можно выразить декларативно.
PE>Проще, но не XML. XML сгодится в качестве промежуточного. Генератор должен XML примнимать, а вот человеку с XML работать не нужно. Слишком много текста и структура плохая.
Практика показывает что стороннему человеку намного проще понимать XML, SQL и прочая, нежели императивный язык. В свое время была задачка обработки потока видео — декларативный стиль описания сети обработчиков инженерам был намного понятнее императивного.
AVK>>Вот смотрел, потому и говорю. WSDL удобнее, более масштабируемо и мощнее.
PE>Ничего тут не удобнее. Если один раз написать и забыть, то можно и XML,WSDL и все, что хочешь юзать.
На вкус и цвет. Мой опыт показывает что С-подобный синтаксис крайне неудобен для декларативного описания, особенно человеку, незнакомому с программированием.
Здравствуйте, AndrewVK, Вы писали:
PE>>Вот в чем дело. Взаимодействие объектов придется частично на этом же языке описывать.
AVK>Взаимодействие тоже можно выразить декларативно.
На XML это неудобно. Не наглядно. Слишком громоздко. Не для этого XML содан.
AVK>Практика показывает что стороннему человеку намного проще понимать XML, SQL и прочая, нежели императивный язык. В свое время была задачка обработки потока видео — декларативный стиль описания сети обработчиков инженерам был намного понятнее императивного.
Понятнее — слишком растяжимо. Могу послать пример на почту.
Достоинства XML в том, что много парсеров написано, он станартизирован и распространен.
На счет понятности — очень спорно. Если текста более, чем на страницу, XML очень трудно читать.
Перепиши мой пример на XML и сам все поймешь.
PE>>Ничего тут не удобнее. Если один раз написать и забыть, то можно и XML,WSDL и все, что хочешь юзать. AVK>На вкус и цвет. Мой опыт показывает что С-подобный синтаксис крайне неудобен для декларативного описания, особенно человеку, незнакомому с программированием.
XML — не простое, а примитивное решение. Все должно быть просто, но не примитивно.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>>Посмотри
VD>Та особо не начто смотреть. В обще, я тебе уже сказал. Сделай поиск... погляди.
Ну да в этих тестах делегаты прогрывают доступ к полю максимум в 5 раз от доступа объекта, и максимально проигрывают интерфейсу в 2 раза.
А у тебя в 5-10 раз к интерфейсу. Причем эти методы тратят время только на вызов не говоря о сложных методах где эта разница будет сведена к нулю. А подумай сам как он может так прогирывать если делает всего 2-3 лишних движения??? Кстати в Delphi нативная крнструкция Procedure of Object работает быстрее виртуального метода (Native), а в случае с интерфейсами это вообще двойная виртуальность.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>Взаимодействие тоже можно выразить декларативно.
PE>На XML это неудобно. Не наглядно.
А по мне так куда удобнее и нагляднее чем то что ты тут приводил.
PE> Слишком громоздко. Не для этого XML содан.
А для чего?
PE>Понятнее — слишком растяжимо. Могу послать пример на почту. PE>Достоинства XML в том, что много парсеров написано, он станартизирован и распространен.
Именно. Особенно подчеркну "стандартизован".
PE>Перепиши мой пример на XML и сам все поймешь.
У меня таких примеров в текущем проекте море. Ничего такого пока не понял. Если слишком много и сложно то и в С-стиле тоже будет малочитаемо, нужно писать специализированный редактор. Просто ты привык к чтению больших объемов С-кода, потому тебе кажется что так проще. На самом же деле при больших объемах проще xml за счет большей структурированности. А учитывая то что для XML уже есть готовые редакторы незнакомому с С человеку он куда предпочтительнее.
PE>XML — не простое, а примитивное решение.
Интересно, на основании чего ты такие выводы делаешь.
Здравствуйте, AndrewVK, Вы писали:
PE>> Слишком громоздко. Не для этого XML содан. AVK>А для чего?
Это не ко мне.
AVK>Именно. Особенно подчеркну "стандартизован". PE>>Перепиши мой пример на XML и сам все поймешь.
AVK>У меня таких примеров в текущем проекте море. Ничего такого пока не понял. Если слишком много и сложно то и в С-стиле тоже будет малочитаемо, нужно писать специализированный редактор. Просто ты привык к чтению больших объемов С-кода, потому тебе кажется что так проще. На самом же деле при больших объемах проще xml за счет большей структурированности. А учитывая то что для XML уже есть готовые редакторы незнакомому с С человеку он куда предпочтительнее.
Редакторы есть какие то. Нет редактора, который отобразит структуру нашей модели.
PE>>XML — не простое, а примитивное решение. AVK>Интересно, на основании чего ты такие выводы делаешь.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>>> Слишком громоздко. Не для этого XML содан. AVK>>А для чего?
PE>Это не ко мне.
Почему? Ты же утверждаешь что не для этого. Вот и интересно тогда для чего.
AVK>>У меня таких примеров в текущем проекте море. Ничего такого пока не понял. Если слишком много и сложно то и в С-стиле тоже будет малочитаемо, нужно писать специализированный редактор. Просто ты привык к чтению больших объемов С-кода, потому тебе кажется что так проще. На самом же деле при больших объемах проще xml за счет большей структурированности. А учитывая то что для XML уже есть готовые редакторы незнакомому с С человеку он куда предпочтительнее.
PE>Редакторы есть какие то. Нет редактора, который отобразит структуру нашей модели.
Редакторы, поддерживающие xsd отображают в соответствии с xsd. Это как минимум базовые взаимосвязи и валидация значений. Для более сложных случаев можешь поглядеть на InfoPath. Для совсем запущенных случаев придется писать свой редактор, а в таком варианте XML безусловно удобнее.
PE>>>XML — не простое, а примитивное решение. AVK>>Интересно, на основании чего ты такие выводы делаешь.
PE>На основании того, что уже сделано.
Ну вобщем поступай как знаешь. Я на основании своего опыта тебе примерное направление показал.
Здравствуйте, AndrewVK, Вы писали:
PE>>>> Слишком громоздко. Не для этого XML содан. AVK>>>А для чего?
PE>>Это не ко мне.
AVK>Почему? Ты же утверждаешь что не для этого. Вот и интересно тогда для чего.
Для хранения, передачи данных например. Но не для декларации сущностей.
AVK>Редакторы, поддерживающие xsd отображают в соответствии с xsd. Это как минимум базовые взаимосвязи и валидация значений. Для более сложных случаев можешь поглядеть на InfoPath. Для совсем запущенных случаев придется писать свой редактор, а в таком варианте XML безусловно удобнее.
Будь все так просто, рулил бы С#+XML или Java+XML. А посмотри, какие тененции — в жаву и нет пихают все, что не лень.
PE>>На основании того, что уже сделано. AVK>Ну вобщем поступай как знаешь. Я на основании своего опыта тебе примерное направление показал.
Я же сказал, что XML для промежуточных данных подходит. А человеку удобнее работать с языком, в котором меньшая избыточность будет и специализированые фичи.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>Редакторы, поддерживающие xsd отображают в соответствии с xsd. Это как минимум базовые взаимосвязи и валидация значений. Для более сложных случаев можешь поглядеть на InfoPath. Для совсем запущенных случаев придется писать свой редактор, а в таком варианте XML безусловно удобнее.
PE>Будь все так просто, рулил бы С#+XML или Java+XML.
А он и рулит. Для определенных задач. JSP и ASP.NET к примеру почти что оно и есть. А XAML точно оно.
PE> А посмотри, какие тененции — в жаву и нет пихают все, что не лень.
В смысле?
PE>Я же сказал, что XML для промежуточных данных подходит.
Ну а мой опыт говорит об обратном. Почему не подходит я от тебя так и не услышал. Аргументы типа "не для этого создан" не катят. Для чего он создан написано на w3c.org.
PE> А человеку удобнее работать с языком, в котором меньшая избыточность будет и специализированые фичи.
Не все так просто. Твой специальный язык человеку придется специально изучать. + неизбежные глюки при самопальной реализации. + необходимость в обязательном порядке собственного редактора. Вобщем специальный язык это крайне дорогое решение, как при разработке так и при использовании.
Здравствуйте, AndrewVK, Вы писали:
PE>>Будь все так просто, рулил бы С#+XML или Java+XML. AVK>А он и рулит. Для определенных задач. JSP и ASP.NET к примеру почти что оно и есть. А XAML точно оно.
PE>> А посмотри, какие тененции — в жаву и нет пихают все, что не лень. AVK>В смысле?
Языки всякие например.
PE>> А человеку удобнее работать с языком, в котором меньшая избыточность будет и специализированые фичи.
AVK>Не все так просто. Твой специальный язык человеку придется специально изучать. + неизбежные глюки при самопальной реализации. + необходимость в обязательном порядке собственного редактора. Вобщем специальный язык это крайне дорогое решение, как при разработке так и при использовании.
Сам XML изучать не нужно. Но нужно будет запоминать все аттрибуты, их порядок, регистр, значения атрибутов и ограничения всякие.
Сравни
Здравствуйте, Plutonia Experiment, Вы писали:
PE>>> А посмотри, какие тененции — в жаву и нет пихают все, что не лень. AVK>>В смысле?
PE>Языки всякие например.
Я же тебе сказал — любая технология хороша в своей области. И не везде императивные языки лучше. Например для кодогенератора XSLT шаблон обычно значительно лаконичнее программы на том же шарпе или джаве. В общем случае чем менее универсально инструментальное средство тем выгоднее декларативное представление. Если в общем случае основная часть модели требует императивного выражения, однако есть и части, которые можно задать декларативно обычно добавляют средства декларативного программирования в императивный язык. Например атрибуты в дотнете. Если же ситуация обратная в декларативное описание добавляют код. Например, как я уже говорил, ASP.NET. Причем, обрати внимание, там есть два разных способа добавления императивной части — embedded код и code behind. Второе применяется когда необходим большой объем кода.
В случае генераторов как правило основная часть исходных данных задается декларативно, иначе просто генератор лишен смысла. Отсюда и XML обычно очень неплохо подходит для этих целей.
AVK>>Не все так просто. Твой специальный язык человеку придется специально изучать. + неизбежные глюки при самопальной реализации. + необходимость в обязательном порядке собственного редактора. Вобщем специальный язык это крайне дорогое решение, как при разработке так и при использовании.
PE>Сам XML изучать не нужно.
Основные принципы XML можно изложить на одной страничке. Кроме того, как ты правильно написал, это стандарт. Поэтому есть немалый шанс что человек уже будет с ним знаком.
PE> Но нужно будет запоминать все аттрибуты,
Нет конечно, это справочная информация.
PE> их порядок,
Это вобще не нужно. Если у тебя что то зависит от порядка атрибутов то это очень криво.
PE> регистр, значения атрибутов и ограничения всякие. PE>Сравни
PE>
Сравнил. Второй вариант для стороннего человека однозначно сложнее. Ты опять делаешь ту же самую ошибку — это для тебя ; в конце строки естественна и не вызывает вопросов. Это для тебя . отделяет классы от атрибутов. Это для тебя применение {} для блоков интуитивно понятно.
Поэтому понять первый вариант не программисту заметно проще. А если еще к нему xsd написать и воспользоваться специализированным редактором, то редактировать данные в гриде сможет совсем уж далекий от программирования человек. Для второго же варианта нужно быть программистом, причем на С-like языке.
Здравствуйте, AndrewVK, Вы писали:
PE>>Языки всякие например.
AVK>Я же тебе сказал — любая технология хороша в своей области. И не везде императивные языки лучше. Например для кодогенератора XSLT шаблон обычно значительно лаконичнее программы на том же шарпе или джаве.
Шаблон генерации в HTML очень похож на этот самый HTML. А если захочешь гнать XML в С#, то шаблон будет очень похож на C#.
PE>> их порядок,
AVK>Это вобще не нужно. Если у тебя что то зависит от порядка атрибутов то это очень криво.
Для XML нужны схемы данных. Это там порядок указывается и регистр.
AVK>Поэтому понять первый вариант не программисту заметно проще. А если еще к нему xsd написать и воспользоваться специализированным редактором, то редактировать данные в гриде сможет совсем уж далекий от программирования человек. Для второго же варианта нужно быть программистом, причем на С-like языке.
В том то и дело. Непрограммисты меня не интересуют вовсе. Наши индейцы(практически все) умеют писать кое что на C++, C# и Яве. Некоторые особо опасные индейцы даже питоном владеют(им так кажется).
В одном случае придется писать редактор, во втором — просто перегонять в XML, с которым и будет работать генератор. Но человеку XML не нужно знать.
. Почему не сделали спец. язык? Потому что слишком долго его делать. А почему не воспользоваться XML+C#? Потому что свой удобнее. 
