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

S>Покажите мне, как будет выглядеть вот этот простенький код в вашей мегасреде:
S>

S>public static IEnumerable<T> Filter<T>(IEnumerable<T> source, Predicate<T> predicate)
S>{
S>  foreach(T item in source) 
S>        if (predicate(item))
S>            yield return item;
S>}
S>

Да элементарно он быдет выглядеть, примерно так:

                                O (IEnumerable<T>)
                                ^
                                |
      +-------------------------+
      |   FILTER <T>     |
      |   ------------------    |
  src |                                                    |
    ----+IEnumerable<T>                        |
            |                                                    |
    pred|                                                 |
  ----+Predicate<T>                            |
        |                                                    |
            +-------------------------+

Это не стеб.

Я автору посоветовал посмотреть на современные навороченные CAD для электронщиков. Заодно можно вспомнить Форт, например. На нем очень многие слова начального уровня пишут на асме, ну а все остальное — уже с помощью этих слов и далее по возрастающей.


S>2. Описать типичные шаги, которые выполняются пользователем в существущем подходе (или нескольких подходах)
S>3. Описать типичные шаги, которые надо будет выполнить в вашем решении.

S>Если речь идет о повышении удобства, то необходимо и достаточно доказать или хотя бы обосновать сокращение количества элементарных действий в п.3. по сравнению с п.2.

А это даже и не надо пока. Достаточно хотя бы достижимости п.3. В визуальных системах кайф от другого можно словить и сэкономить время в совсем другом месте. Я тут постоянно говорю, что миллионы программистов все время пишут одно и то же, при чем при любом масштабе рассмотрения вопроса, от глобальных задач, до конкретных участков кода. И отлаживают это постоянно. Не задумывался, почему ПО глючит куда как чаще железа? Доходит до того, что глюки современного "железа" идут от ПО, которое это железо содержит.

V>А вот и зря. Идея эта не нова и даже тут неоднократно обсуждалась. Ведь электронщики давно делают предложенное, правда?
V>Сделать т.н. "ядро" для рендеринга модели в готовый код не так уж и сложно. Ты бы лучше покумекал насчет того, как это будет выглядеть. Для примера показал бы процесс графического (юзером в GUI) составления хотя бы несложных алгоритмов, или ORM данных из базы на некую иерархию объектов.
V>(Очень рекомендую много посидеть в различных сложных CAD-системах для электронщиков, может это подскажет тебе что-нить )

хе... только электронщики начали понимать сложность диаграмм для описания ЛОГИКИ, и придумали для себя язык VHDL + ППЛМ и его эмуляторы( что то типа компилятора и отладчика в терминах программиста), после чего создание электронной логики вышло на качественно новый уровень , так что пока мир идет к описанию на языках автор идет в обратном направлени не желая ничего слушать.

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

                O (IEnumerable<T>)
                ^
                |
      +-----------------------+
      |      FILTER<T>        |
      |   ------------------  |
  src |                       |
  ----+IEnumerable<T>         |
      |                       |
  pred|                       |
  ----+Predicate<T>           |
      |                       |
      +-----------------------+

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

V>Среди диаграмм UML нет чего-то типа блок-схемы алгоритма, к сожалению.

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

*
    A
    +
        B
        C

Вместо A*(B+C)никто не делает.

AVK>>Конечно же это не так. Весь дизайн-тайм компонентов это чистая динамика.

V>И зачем ты издеваешься над ним?

Ну а что еще остается? Слушать разумные советы он явно не хочет.

V>А генерики в дотнете, к сожалению, не могут обслужить даже такую мелочь, как подстановка различных численных типов в некие алгоритмы, требущие вычислений. И вот мы получаем искусственное дробление одного контракта на тонны дублирующих (тонны из-за комбинаторных сочетаний различных типов).

Не знаю. Мне как то обычно удавалось обойтись без этого.

V> И вот получаем отсутствие реюза на ровном месте. Некоторые динамические языки в этом плане гораздо более реюзабельны (Смолтолк, Схема).

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

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

V>ИМХО, в такой системе библиотеки должны быть не в виде бинарных компонент, а в виде параметризируемых паттернов и шаблонов будущих целевых компонент как результата работы системы.

Увы, эта идея малореализуема на практике. Together революцию в итоге так и не совершил.

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

_JK>хе... только электронщики начали понимать сложность диаграмм для описания ЛОГИКИ, и придумали для себя язык VHDL + ППЛМ и его эмуляторы( что то типа компилятора и отладчика в терминах программиста), после чего создание электронной логики вышло на качественно новый уровень , так что пока мир идет к описанию на языках автор идет в обратном направлени не желая ничего слушать.

Ты ошибаешься. В обратном направлении никто не идет. Что удобно делать визуально — делают визуально, что удобно написать ручками (обычно мелочи и формулы вычислений), то делают ручками. Уровень автоматизации разработки у электронщиков на порядки выше чем в ПО.

Мне нравился одно время Together от Борланда (вернее, бывшая купленная Питерская разработка). Там синхронно можно изменять код и UML. Когда я разрабатывал иерархии классов и общую структуру, то в Together это было делать быстрее всего, именно из-за их концепции two-way editing.

Дело еще в том, что UML нифига не приспособлен для кодирования/представления непосредственного кода, но по крайней мере диаграмма классов пользу приносит для накидывания описаний.

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

V>>ИМХО, в такой системе библиотеки должны быть не в виде бинарных компонент, а в виде параметризируемых паттернов и шаблонов будущих целевых компонент как результата работы системы.

AVK>Увы, эта идея малореализуема на практике. Together революцию в итоге так и не совершил.

Он двигался в павильном направлении, но програл одному конкуренту (JIDEA) в сиюминутно востребованной фиче: мощи рефакторинга. Другому конкуренту (Rational XDE) програл в удобстве и мощи GUI UML-редактора и в степени интегрированности со студией (когда сунулся и на это поле). На поле Java он проиграл в цене Эклипсу. Дополнительно каждому из них проиграл в быстродействии (что было естественно для их технологии).

Естественно, что пользователи не захотели приобретать новые повадки, и при этом отказываться от старых-любимых. Если попытку Together повторит IDEA, то их вполне может ожидать успех. У них что-то такое DSL-ное, визуальное и метакодное уже есть. Они просто сделали коньюктурно правильную ставку на текущие потребности, и не ошиблись. Сами разработчики, если помнишь, говорили, что им карты спутал выход .Net 2.0, когда им пришлось все силы бросить на поддержку новых спецификаций дотнета и студии, плюс отладку решарпера, отодвинув визуальные проекты на 2-3 года.

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

V>Он двигался в павильном направлении, но програл одному конкуренту (JIDEA) в сиюминутно востребованной фиче: мощи рефакторинга. Другому конкуренту (Rational XDE) програл в удобстве и мощи GUI UML-редактора и в степени интегрированности со студией (когда сунулся и на это поле). На поле Java он проиграл в цене Эклипсу. Дополнительно каждому из них проиграл в быстродействии (что было естественно для их технологии).

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

V>Ты ошибаешься. В обратном направлении никто не идет. Что удобно делать визуально — делают визуально, что удобно написать ручками (обычно мелочи и формулы вычислений), то делают ручками. Уровень автоматизации разработки у электронщиков на порядки выше чем в ПО.
возможно придут настоящие электронщики они нас рассудят, но одно время в универе я работал на кафедре, где делали спец процессоры для спец плат, так вот что то я там не заметил чтобы только мелочи только на VHDL делали, да и не представляю как можно на нем делать мелочи, если на нем все абсолютно нормально описыватся, ну может только схемы переходов для конечного автомата рисовали редактором чтобы для них автоматом код на VHDL генерился, хотя его не так трудно и руками набросать. коллектив был очень проффессиональный люди в нем уже 10 лет на этом руку набивали все были как минимум phD. cs.
так что кто прав а кто нет еще не известно.

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


_JK>так что кто прав а кто нет еще не известно.

Процессоры мало кто разрабатывает. А свои спец-платы вы на чем делали?

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

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

V>

V>                O (IEnumerable<T>)
V>                ^
V>                |
V>      +-----------------------+
V>      |      FILTER<T>        |
V>      |   ------------------  |
V>  src |                       |
V>  ----+IEnumerable<T>         |
V>      |                       |
V>  pred|                       |
V>  ----+Predicate<T>           |
V>      |                       |
V>      +-----------------------+
V>

Не вижу содержимого.

_JK>>так что кто прав а кто нет еще не известно.
V>Процессоры мало кто разрабатывает. А свои спец-платы вы на чем делали?

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

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

_JK>>>так что кто прав а кто нет еще не известно.
V>>Процессоры мало кто разрабатывает. А свои спец-платы вы на чем делали?

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

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

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

Почему индустрия до сих пор еще не созрела до такого разделения труда? ИМХО потому, что в ЛЮБОМ прикладном проекте присутствует значительная доля системного когда. Иногда его более половины (!!!). Мне лично удавалось писать прикладной код без единой строчки системного только на MS Access, и результат на лицо: 80-90% всех работ там делаются визуально и это все работает сразу без нудной отладки. Естественно, что речь шла о небольших задачах, потребности которых полностью этим MS Access покрывались. В последнем предложении намек.

V>Возвращаясь к тому, с чего начали обсуждение, для ПО это будет означать примерно то же самое:
V>- "системные" блоки удобнее всего описывать на языках программирования.
V>- лепить из готовых низко- и высоко-уровневых блоков прикладной код ИМХО будет удобнее в визуальных средах.

так зачем тогда делать какую то среду??? все уже давно придумано до нас
1.Delphi/Builder
2.Excel/Access/FoxPro
3.Visual Basic

и т.д.

все эти средства позволяют сделать формы и т.п. для примитивных приложений типа принеси подай и кушать подано... но как только появляется что то сложнее hello world, тут же все преимущества визуального программирования гаснут и никакой существенной пользы, ускорения программирования, и всего остального не приносят.

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


V>>

V>>                O (IEnumerable<T>)
V>>                ^
V>>                |
V>>      +-----------------------+
V>>      |      FILTER<T>        |
V>>      |   ------------------  |
V>>  src |                       |
V>>  ----+IEnumerable<T>         |
V>>      |                       |
V>>  pred|                       |
V>>  ----+Predicate<T>           |
V>>      |                       |
V>>      +-----------------------+
V>>

S>Не вижу содержимого.

Тогда поясню. В визуальных средах для электронщиков, на том месте где написано Filter<T> пишут марку микросхемы или ее обобщенное название (на блок-схемах). В системах, где упор делается на моделирование, вместо безликих "квадратиков" для внешнего представления компонент могут быть использованы более выразительные образы. Для нашего примера это может быть стиллизованное графическое представление фильтра (в виде привычной воронки, например).

Остальной ход рассуждений здесь: Re[15]: Как вам задумка, а?

Автор: vdimas
Дата: 16.10.06

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

V>>Возвращаясь к тому, с чего начали обсуждение, для ПО это будет означать примерно то же самое:
V>>- "системные" блоки удобнее всего описывать на языках программирования.
V>>- лепить из готовых низко- и высоко-уровневых блоков прикладной код ИМХО будет удобнее в визуальных средах.

_JK>так зачем тогда делать какую то среду??? все уже давно придумано до нас
_JK>1.Delphi/Builder
_JK>2.Excel/Access/FoxPro
_JK>3.Visual Basic

_JK>и т.д.

Этим всем вещам уже по 10 и более лет.


_JK>все эти средства позволяют сделать формы и т.п. для примитивных приложений типа принеси подай и кушать подано... но как только появляется что то сложнее hello world, тут же все преимущества визуального программирования гаснут и никакой существенной пользы, ускорения программирования, и всего остального не приносят.

Можно пример того сложного, о чем речь? Я вот уникальные задачи вижу очень и очень редко. А любую повторяемую "сложность" давно пора было вывести на уровень аксессов.

_JK>>все эти средства позволяют сделать формы и т.п. для примитивных приложений типа принеси подай и кушать подано... но как только появляется что то сложнее hello world, тут же все преимущества визуального программирования гаснут и никакой существенной пользы, ускорения программирования, и всего остального не приносят.

V>Можно пример того сложного, о чем речь? Я вот уникальные задачи вижу очень и очень редко. А любую повторяемую "сложность" давно пора было вывести на уровень аксессов.

я например работаю над распределенной OLAP системой с большими объемами данных (порядка 15гб) масштабируемая, 24/7, load balancing, центральная система администрирования, объектная база данных( для user объектов), порядка 6 видов абсолютно разных клиентов, механизмы экспорта и импорта, заточена под спец данные, рассылки по email, sms, batch jobs, спец система авторизации плотная интеграция с другими продуктами заказчиков и много всего другого...

пример отчет за год (~3гб обрабатываемых данных) на нашей системе идет ~2мин.
если делать все тоже к примеру на oracle то за год отчет не строится ВООБЩЕ (т.е не оракл уходит в себя дождаться на смогли)
если строить отчет за квартал — у нас ~30сек у оракла — 4 часа.

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

основной объем работы — сервер (алгоритмы, структуры данных, никакого UI) код уникален.

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

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


V>Почему индустрия до сих пор еще не созрела до такого разделения труда?

Почему не созрела? Компоненты и визуальные редакторы придуманы давным давно. Визуальный редактор форм уже стал стандартом. В 2005 студии штатно есть class designer графический.
А то, что логику нельзя так рисовать, так об этом тебе и говорят. Не везде идеология собирания программы из готовых блоков удобна и уместна.

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


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

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

V>Тогда поясню. В визуальных средах для электронщиков, на том месте где написано Filter<T> пишут марку микросхемы или ее обобщенное название (на блок-схемах). В системах, где упор делается на моделирование, вместо безликих "квадратиков" для внешнего представления компонент могут быть использованы более выразительные образы. Для нашего примера это может быть стиллизованное графическое представление фильтра (в виде привычной воронки, например).

как в анекдоте про такси — "вам шашечки или ехать?"

программистам не надо красивости и т.п. им надо чтобы алгоритмы были правильные и архитектура в целом.
что до дизайнеров и всего остального НУ НЕ НУЖНЫ ОНИ в большинстве случаев, может быть только в начале обучения когда проходит стадия "изучаю VC2003 за 24 урока ",

я например не пользуюсь вообще никакими дизайнерами классвизардами и прочим(кроме редактора ресурсов), как показывает практика если знаешь что писать руками набивать быстрее проще и надежней. и вообще большУю часть работы пишу в редакторе от Far-а.

так и тут — не надо грузить программиста разглядыванием всяких картинок "стилизованных", работа программиста — продумывать механизмы взаимодействия частей системы в целом, подбор правильных алгоритмов, налаживание взаимодействия между частями системы и продумывание ситем ввода-вывода, и паралельно код строчить..., это совсем не сложно и не надо тут ничего упрощать...
как говорит дядя Паретт 80/20
80% времени создается и обдумывается архитектура
20% пишется код....
(а на самом деле может и 95/5)

небольшое ускорение написания кода — бессмысленная трата времени.... надо архитектура быстрее и лучше продумывалась, чтобы её потом еще 5-10 раз пересмотреть не пришлось, а для это не тулзы нужы а мозги и развивать их надо посещением лекций чтением литературы и т.д. тогда можно получить большой прирост производительности.

короче говоря: 1 хороший проффессионал имея под рукой любой текстовый редактор и компилятор, решит задачу быстрее, лучше и эффективнее, чем комманда из 10 так себе программеров до зубов вооруженных вспомогательными IDE, тулзами, дебаггерами, профилерами, редакторами, UML и т.д. и т.п