Здравствуйте, vdimas, Вы писали:
V>И я даже знаю, где проходит граница м/у этими "не везде". Всё, что можно описать декларативно, теоретически вполне поддается визуальному дизайну и параметризации. Я считаю, что процент императивного пока что неоправданно высок. Я бы оставил в большинстве случаев только формулы какие-нить.
Так вот, возвращаясь к исходному сообщению топика — очевидно, что нужно сначала обдумать, что и как должно быть декларативно, а уж потом бросаться делать супер-пупер продукт.
_JK>как говорит дядя Паретт 80/20 _JK>80% времени создается и обдумывается архитектура _JK>20% пишется код....
Вот об этих 80-ти и речь. Ты всерьез думаешь, что мне нужны ср-ва для оставшихся 20-ти? Студия с решарпером вполне покрывают мои потребности. Речь идет о том, чтобы спроектированное решение сразу же можно было бы опробовать, потом параметризировать по-другому и опять пробовать, сравнивать, прогонять различные сценарии. Блин, ведь львиное большинство современных требований к ПО являются нефункциональными, а львиная часть нефункциональных требований формулируется исходя из субъективных представлений разработчика системы о наиболее применимых сценариях и условиях их выполнений. И возможности на эксперимент и выбор вариантов нет. Обычно как спроектировали, так и кодируют. Если выяснится, что на этапе проектирования допущена серьезная ошибка, то многое из того, что накодили, автоматически превращается в мусор. Иногда весь проект превращается в мусор. Так понятней?
_JK>небольшое ускорение написания кода — бессмысленная трата времени.... надо архитектура быстрее и лучше продумывалась, чтобы её потом еще 5-10 раз пересмотреть не пришлось,
Да ну? А мне именно хочется раз 5-10 пересмотреть, более того — сравнить варианты.
_JK>а для это не тулзы нужы а мозги и развивать их надо посещением лекций чтением литературы и т.д.
Фантастика.
Даже если ты вдвое разовьешь свои мозги, тебе не избежать проблем, связанных со сложностью современных систем, на несколько порядков превышающих возможности одного человеческого мозга. Для примера, ты же не станешь говорить, что вместо использования КОП надо получше развивать свои мозги. А ведь КОП и обсуждаемое — это по-сути движение в одном и том же направлении. (аналогично: структурная, объектная, функциональная декомпозиция).
_JK>короче говоря: 1 хороший проффессионал имея под рукой любой текстовый редактор и компилятор, решит задачу быстрее, лучше и эффективнее, чем комманда из 10 так себе программеров до зубов вооруженных вспомогательными IDE, тулзами, дебаггерами, профилерами, редакторами, UML и т.д. и т.п
Согласен, но меня не интересует ситуация из 10 так себе программеров. Меня как раз интересует возможность именно одного хорошего профессионала. А он, дорогой наш профессионал, будучи сам-на-сам, даже используя самые навороченные ср-ва, физически не может удовлетворить запросы на сложность современных систем. Про ситуацию работы профессиюнала в ФАР-е — это не ко мне, это к PHP-шникам.
Здравствуйте, _JoKe_, Вы писали:
_JK>пример отчет за год (~3гб обрабатываемых данных) на нашей системе идет ~2мин. _JK>если делать все тоже к примеру на oracle то за год отчет не строится ВООБЩЕ (т.е не оракл уходит в себя дождаться на смогли) _JK>если строить отчет за квартал — у нас ~30сек у оракла — 4 часа.
Язык PL Оракла — плохой пример для императивной обработки данных, ибо работает не очень быстро. Что это доказывает? Если вашу систему долго и нудно оптимизировать на С++, то уверен, можно получить даже лучшие показатели чем ты привел. Но это опять же ничего не демонстрирует.
_JK>любой другой обобщенный продукт дает примерно такие же показатели как и оракл, да и не учитывает спец особенностей данных и т.п.
Вы пробовали Cache и другие объектно-ориентированные базы с бинарной компиляцией методов?
_JK>если предположить что все варианты кода в мире систематизируется и складывается в гипотетическое хранилище (задача сама по себе слабо решаемая), то я сомневаюсь что найти среди миллиардов различных отрывков кода нужный тебе, проверить его что это действительно то что тебе надо и оттестировать в реальном проекте будет проще и быстрее, чем написать свой.
Все варианты для начала обобщаются с целью дальнейшей параметризации. Ну а насчет того, что найти будет дольше, чем написать — вообще ерунда. У меня на компе сотни тысяч файлов, однако найти любой из них несложно. Намек понял?
Миллиард — это перебор. Я бы оценил кол-во задач низкого уровня в десяток тысяч, и то, жестко каталогизированных. Остальные параметризируемые компоненты более высокого уровня могли бы быть построены на основе этих системных. Типовых строительных блоков среднего уровня — вообще не много. Ну а все разнообразие конечных решений могло бы быть построено на этом middleware + системные ср-ва. Ну еще могло бы быть несколько тысяч каталогизированных типовых стартер-китов, типа: типовой блок веб-магазина, типовой блок внутрикорпоративной оптовой продажи, десятки типовых аналитических блоков и т.д.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, _JoKe_, Вы писали:
_JK>>пример отчет за год (~3гб обрабатываемых данных) на нашей системе идет ~2мин. _JK>>если делать все тоже к примеру на oracle то за год отчет не строится ВООБЩЕ (т.е не оракл уходит в себя дождаться на смогли) _JK>>если строить отчет за квартал — у нас ~30сек у оракла — 4 часа.
V>Язык PL Оракла — плохой пример для императивной обработки данных, ибо работает не очень быстро. Что это доказывает? Если вашу систему долго и нудно оптимизировать на С++, то уверен, можно получить даже лучшие показатели чем ты привел. Но это опять же ничего не демонстрирует.
мой пример совсем не о том какой язык лучше
ты не понял... причем тут язык пл? я имею ввиду то что узкоспециализированное средство всегда лучше обобщенного.
_JK>>любой другой обобщенный продукт дает примерно такие же показатели как и оракл, да и не учитывает спец особенностей данных и т.п. V>Вы пробовали Cache и другие объектно-ориентированные базы с бинарной компиляцией методов?
читай внимательно ОО база у нас только для того чтобы было удобно хранить ЮЗЕР-объекты там не нужна скорость просто нужно удобное хранилище, сейчас это выглядит так как работа с обычными C++ объектами т.е obj->method(), obj->field а уже по операции -> происходит если нужно передача по сети, кэши, бэкапы, сериализация и т.п. все. больше от базы ничего не требуется в ней нет никаких методов и всего остального.
_JK>>если предположить что все варианты кода в мире систематизируется и складывается в гипотетическое хранилище (задача сама по себе слабо решаемая), то я сомневаюсь что найти среди миллиардов различных отрывков кода нужный тебе, проверить его что это действительно то что тебе надо и оттестировать в реальном проекте будет проще и быстрее, чем написать свой. V>Все варианты для начала обобщаются с целью дальнейшей параметризации.
ну ну... хотя бы задачу параметризации и поиска для начала решить надо... а задача ой какая не простая... после того как будет это решение — супер система программирования мышкой не нужна будет.... я и в коде все склею..
V>Ну а насчет того, что найти будет дольше, чем написать — вообще ерунда. У меня на компе сотни тысяч файлов, однако найти любой из них несложно. Намек понял?
это на твоем СОБСТВЕННОМ компе...
у себя мне и параметризовать ничего надо я и так знаю какой код У СЕБЯ взять за основу и что в нем подправить чтобы что то получить.
а вот глобально обобщить....
попробуй найди в сети допустим методику расчета потенциала целевой группы для покупок кроссовок на рынке США.
V>Миллиард — это перебор. Я бы оценил кол-во задач низкого уровня в десяток тысяч, и то, жестко каталогизированных. Остальные параметризируемые компоненты более высокого уровня могли бы быть построены на основе этих системных. Типовых строительных блоков среднего уровня — вообще не много. Ну а все разнообразие конечных решений могло бы быть построено на этом middleware + системные ср-ва. Ну еще могло бы быть несколько тысяч каталогизированных типовых стартер-китов, типа: типовой блок веб-магазина, типовой блок внутрикорпоративной оптовой продажи, десятки типовых аналитических блоков и т.д.
далеко не все задачи представляют собой системы онлайн заказов, бухгалтерию, и документооборот — как представляют себе некоторые программисты....
есть очень много специализированных областей программирование которых абсолютно не похоже на создание формочек из того что я сказал выше.
_JK>>как говорит дядя Паретт 80/20 _JK>>80% времени создается и обдумывается архитектура _JK>>20% пишется код....
V>Вот об этих 80-ти и речь. Ты всерьез думаешь, что мне нужны ср-ва для оставшихся 20-ти? Студия с решарпером вполне покрывают мои потребности. Речь идет о том, чтобы спроектированное решение сразу же можно было бы опробовать, потом параметризировать по-другому и опять пробовать, сравнивать, прогонять различные сценарии. Блин, ведь львиное большинство современных требований к ПО являются нефункциональными, а львиная часть нефункциональных требований формулируется исходя из субъективных представлений разработчика системы о наиболее применимых сценариях и условиях их выполнений. И возможности на эксперимент и выбор вариантов нет. Обычно как спроектировали, так и кодируют. Если выяснится, что на этапе проектирования допущена серьезная ошибка, то многое из того, что накодили, автоматически превращается в мусор. Иногда весь проект превращается в мусор. Так понятней?
бред- читай внимательнее 80 а то и 95% времени занимает АНАЛИЗ И РАЗРАБОТКА АРХИТЕКТУРЫ( НЕ КОДИРОВАНИЕ ),а остальное кодирование, если что то не получилось то все равно следующая итерация ничего не меняет опять МНОГО ДУМАЕМ, быстро кодируем. или МАЛО ДУМАЕМ и еще НАМНОГО МЕНЬШЕ занимаемся кодированием.
_JK>>небольшое ускорение написания кода — бессмысленная трата времени.... надо архитектура быстрее и лучше продумывалась, чтобы её потом еще 5-10 раз пересмотреть не пришлось, V>Да ну? А мне именно хочется раз 5-10 пересмотреть, более того — сравнить варианты.
если это примитивная задача получится с первого раза, если сложная то 5-10 раз пересмотреть это 95% думать и 5% давить на клавиши.
если не понятно объясняю еще раз после того как я день буду думать МНЕ АБСОЛЮТНО ВСЕ РАВНО в результате чего я получу программу, будь то 10-ти минутное волтузанье мышкой или получасовое давление на кнопки (хотя я все равно уверен что по времени на кнопках быстрее)
_JK>>а для это не тулзы нужы а мозги и развивать их надо посещением лекций чтением литературы и т.д.
V>Фантастика. V>Даже если ты вдвое разовьешь свои мозги, тебе не избежать проблем, связанных со сложностью современных систем, на несколько порядков превышающих возможности одного человеческого мозга. Для примера, ты же не станешь говорить, что вместо использования КОП надо получше развивать свои мозги. А ведь КОП и обсуждаемое — это по-сути движение в одном и том же направлении. (аналогично: структурная, объектная, функциональная декомпозиция).
бред. нет большой сложности в современных системах, главная сложность в предметной области а не в IT.
_JK>>короче говоря: 1 хороший проффессионал имея под рукой любой текстовый редактор и компилятор, решит задачу быстрее, лучше и эффективнее, чем комманда из 10 так себе программеров до зубов вооруженных вспомогательными IDE, тулзами, дебаггерами, профилерами, редакторами, UML и т.д. и т.п
V>Согласен, но меня не интересует ситуация из 10 так себе программеров. Меня как раз интересует возможность именно одного хорошего профессионала. А он, дорогой наш профессионал, будучи сам-на-сам, даже используя самые навороченные ср-ва, физически не может удовлетворить запросы на сложность современных систем. Про ситуацию работы профессиюнала в ФАР-е — это не ко мне, это к PHP-шникам.
еще раз НЕТ БОЛЬШОЙ СЛОЖНОСТИ В СОВРЕМЕННЫХ СИСТЕМАХ.
про фар не понял, я в фаре пишу на C++, javascript, C#, html, xml и на всем что представлено ввиде текста если затраты на загрузку/выгрузку спец среды приближаются к затратам на написание кода.
Здравствуйте, _JoKe_, Вы писали:
_JK>мой пример совсем не о том какой язык лучше _JK>ты не понял... причем тут язык пл? я имею ввиду то что узкоспециализированное средство всегда лучше обобщенного.
Не согласен, извини. Узкоспециализированных задач настолько мало, что даже не хочется их обсуждать. Подавляющее кол-во востребованных рынком задач весьма однотипны.
А при чем тут PL? Фиг его знает, ты же начал с Ораклом свою систему сравнивать, а я точно знаю, что Оракл проигрывает минимум на порядок С++ в случае нецелевого его использования для проигрывания императивных алгоритмов.
_JK>>>любой другой обобщенный продукт дает примерно такие же показатели как и оракл, да и не учитывает спец особенностей данных и т.п. V>>Вы пробовали Cache и другие объектно-ориентированные базы с бинарной компиляцией методов?
_JK>читай внимательно ОО база у нас только для того чтобы было удобно хранить ЮЗЕР-объекты там не нужна скорость просто нужно удобное хранилище, сейчас это выглядит так как работа с обычными C++ объектами т.е obj->method(), obj->field а уже по операции -> происходит если нужно передача по сети, кэши, бэкапы, сериализация и т.п. все. больше от базы ничего не требуется в ней нет никаких методов и всего остального.
Мне вообще-то плевать как именно это сделано у вас. Я спросил — вы по быстродейтсвию сравнивать свои алгоритмы в вашей системе с оными в Cache пробовали, прежде чем воротить свое аналогичное?
_JK>>>если предположить что все варианты кода в мире систематизируется и складывается в гипотетическое хранилище (задача сама по себе слабо решаемая), то я сомневаюсь что найти среди миллиардов различных отрывков кода нужный тебе, проверить его что это действительно то что тебе надо и оттестировать в реальном проекте будет проще и быстрее, чем написать свой. V>>Все варианты для начала обобщаются с целью дальнейшей параметризации. _JK>ну ну... хотя бы задачу параметризации и поиска для начала решить надо... а задача ой какая не простая... после того как будет это решение — супер система программирования мышкой не нужна будет.... я и в коде все склею..
Имелось ввиду — параметризация типами. Можно сюда подробней, что там сложного с параметризацией поиска? Заодно напомню, что я для ручного ввода зарезервировал такую вещь, как формулы.
V>>Ну а насчет того, что найти будет дольше, чем написать — вообще ерунда. У меня на компе сотни тысяч файлов, однако найти любой из них несложно. Намек понял? _JK>это на твоем СОБСТВЕННОМ компе... _JK>у себя мне и параметризовать ничего надо я и так знаю какой код У СЕБЯ взять за основу и что в нем подправить чтобы что то получить. _JK>а вот глобально обобщить....
Ой страшно. Вон в Java и дотнет уже дофига, вообще-то глобально обобщили, десятки и сотни тысяч типов по частоиспользуемым сборкам раскиданы, и прекрасно народ пользуется, ибо малость каталогизированно.
_JK>попробуй найди в сети допустим методику расчета потенциала целевой группы для покупок кроссовок на рынке США.
Можно я все же формулы буду руками вводить? Ибо многие задачи только формулами и данными и отличаются.
_JK>есть очень много специализированных областей программирование которых абсолютно не похоже на создание формочек из того что я сказал выше.
Диктую большими буквами — этих областей очень мало. Можешь попытаться их прямо здесь перечислить. Не стесняйся, фантазируй, будет интересно прикинуть их уникальность
_JK>бред- читай внимательнее 80 а то и 95% времени занимает АНАЛИЗ И РАЗРАБОТКА АРХИТЕКТУРЫ( НЕ КОДИРОВАНИЕ ),а остальное кодирование, если что то не получилось то все равно следующая итерация ничего не меняет опять МНОГО ДУМАЕМ, быстро кодируем. или МАЛО ДУМАЕМ и еще НАМНОГО МЕНЬШЕ занимаемся кодированием.
Это ты учебников начитался. На самом деле в эти 80% "забивается" все время, необходимое на поиск конечной архитектуры. (95% почти никогда, будь уверен, ибо еще тестирование не забудь, а если добавить внедрение, фидбэк и доделки, то дай бог 30-40% останется) А состав этого "забитого" времени примерно таков: 10% — наброски идей, 90% моделирование и тестирование идей, проверка на совместимость с требованиями и т.д. Процесс очень постепенный и итеративный именно из-за нудных постоянных проверок на совместимость с требованиями старыми и новыми уточняющими, возникшими на предыдущей итерации, т.е. из-за необходимости убеждаться, что не поломали более абстрактную модель, выстроенную на предыдущих шагах итерации. Я хочу избавиться от этих 90%, ибо считаю эту работу тупой. Подобная проектная деятельность интересна только первые 5-7 лет, затем ты чётко ощущаешь, что тратишь свое драгоценное время на очередную нудную херню, использующую твой мозг исключительно на уровне рефлексов.
Чем больше и сложнее проект, тем меньший процент занимает собственно генерирование идей, и все больший процент занимает их реализация (или же детализация на нижних уровнях проектирования). Кстати, по мне разработка подробных моделей ничем не отличается от кодинга. Кодинг требует собранности не меньнше, а может и больше, чем трассировка архитектуры. Общее у них в ощущениях: "я все это уже 100 раз когда-то делал".
_JK>>>небольшое ускорение написания кода — бессмысленная трата времени.... надо архитектура быстрее и лучше продумывалась, чтобы её потом еще 5-10 раз пересмотреть не пришлось, V>>Да ну? А мне именно хочется раз 5-10 пересмотреть, более того — сравнить варианты. _JK>если это примитивная задача получится с первого раза, если сложная то 5-10 раз пересмотреть это 95% думать и 5% давить на клавиши.
Ну найчи меня правильно думать мистер ГЕНИЙ. Что-то у меня не получается в последние годы одновременной удерживать в памяти даже 5% от собственных проектов. И как в таких условиях думать все 95%? "Трясти" приходится.
_JK>если не понятно объясняю еще раз после того как я день буду думать МНЕ АБСОЛЮТНО ВСЕ РАВНО в результате чего я получу программу, будь то 10-ти минутное волтузанье мышкой или получасовое давление на кнопки (хотя я все равно уверен что по времени на кнопках быстрее)
Я вот все тебе намекаю, намекаю. В общем, если еще не догадался, в следующем посте открою, в чем тут засада, и почему я никогда не "думаю" целыми днями, а предпочитаю свои идеи тут же обращать в некую более-менее твердую копию. (необязательно код)
_JK>>>а для это не тулзы нужы а мозги и развивать их надо посещением лекций чтением литературы и т.д.
V>>Фантастика. V>>Даже если ты вдвое разовьешь свои мозги, тебе не избежать проблем, связанных со сложностью современных систем, на несколько порядков превышающих возможности одного человеческого мозга. Для примера, ты же не станешь говорить, что вместо использования КОП надо получше развивать свои мозги. А ведь КОП и обсуждаемое — это по-сути движение в одном и том же направлении. (аналогично: структурная, объектная, функциональная декомпозиция).
_JK>бред. нет большой сложности в современных системах, главная сложность в предметной области а не в IT.
1. Ты не ответил на мой аргумент с КОП, т.е. не подтвердил свое предыдущее высказывание.
2. Твое заявление малость выпало из темы предыдущего абзаца, ибо есть кучи спецов, отлично разбирающихся в некоей предметной области, но неспособных реализовать свои знания в адекватных системах автоматизации деятельности в рамках этой области. Достоинство проектировщиков — в умении моделировать предметные области. Я бы не назвал это "сложностью", это некое умение, где определенную роль играет талант. У кого есть талант и навык, тому вовсе несложно моделировать даже незнакомые предметные области, если есть внятные требования/пожелания к автоматизации. В общем, это все отдельная тема, и к развитию мозга отношение не имеет. Почитай, кто такие бизнес-аналитики. По-твоему, они обязательно умнее или глупее проектировщиков? Эти навыки абсолютно перпендикулярны, а ты мешаешь их в одну кучу сейчас.
_JK>>>короче говоря: 1 хороший проффессионал имея под рукой любой текстовый редактор и компилятор, решит задачу быстрее, лучше и эффективнее, чем комманда из 10 так себе программеров до зубов вооруженных вспомогательными IDE, тулзами, дебаггерами, профилерами, редакторами, UML и т.д. и т.п
V>>Согласен, но меня не интересует ситуация из 10 так себе программеров. Меня как раз интересует возможность именно одного хорошего профессионала. А он, дорогой наш профессионал, будучи сам-на-сам, даже используя самые навороченные ср-ва, физически не может удовлетворить запросы на сложность современных систем. Про ситуацию работы профессиюнала в ФАР-е — это не ко мне, это к PHP-шникам.
_JK>еще раз НЕТ БОЛЬШОЙ СЛОЖНОСТИ В СОВРЕМЕННЫХ СИСТЕМАХ.
Тогда сразу сворачиваем обсуждение, ибо я базируюсь на том, что сложность давно зашкаливает. Иначе бы я даже не участвовал в обсуждении здесь.
_JK>про фар не понял, я в фаре пишу на C++, javascript, C#, html, xml и на всем что представлено ввиде текста если затраты на загрузку/выгрузку спец среды приближаются к затратам на написание кода.
И ты наизусть помнишь все тысячи типов и все их десятки тысяч методов этих типов из твоего проекта? И еще в 10 раз больше библиотечных типов и их методов? НЕ ВЕРЮ. Вот у меня загружается студия, там около 30 проектов, в совокупности составляющих лишь одну из частей нашей системы. Уметь помнить все подробности всех проектов наизусть чтобы мочь писать/отлаживать в ФАРе быстрее, чем грузится студия? Я бы многое отдал за это.
Здравствуйте, vdimas, Вы писали:
V>Тогда поясню. В визуальных средах для электронщиков, на том месте где написано Filter<T> пишут марку микросхемы или ее обобщенное название (на блок-схемах). В системах, где упор делается на моделирование, вместо безликих "квадратиков" для внешнего представления компонент могут быть использованы более выразительные образы. Для нашего примера это может быть стиллизованное графическое представление фильтра (в виде привычной воронки, например).
Отлично. Вопрос был в том, как представить код метода, написанного пользователем.
Я в упор не могу понять, какой ИИ нужен для того, чтобы по приведенным мной строчкам нарисовать воронку. На всякий случай приведу эти строчки еще раз:
public static IEnumerable<T> Filter<T>(IEnumerable<T> source, Predicate<T> predicate)
{ foreach(T item in source)
if (predicate(item))
yield return item;
Он к сожалению не имеет отношения к моему вопросу.
Он имеет отношение к вещам, которые изобретены безумное количество лет назад. То, как вы восприняли мечты Анонима, можно вживую наблюдать в любой скада-системе моложе 15 лет.
Элементарные соображения здравого смысла приводят нас к пониманию того, что аналогичные средства программирования до сих пор не очень-то применяются в мейнстриме не потому, что их невозможно написать, а потому, что выхлоп будет невысоким. В нишевых областях визуальное программирование вполне рулит — вон можно глянуть в редакторы Workflow в BizTalk или Workflow Foundation Framework. Но надо понимать, что никто не ожидает столь же визуального программирования элементов этой картинки. Не работает сие. Вот нарисуйте полное графическое представление приведенного мной метода Filter, ужаснитесь и убедитесь.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Синклер, ты нудный. В той ссылке я говорил о том, что многие базовые вещи действительно удобно описывать на ЯП. Возьми, например, среду моделирования Electronic Workbench. Я тоже ума не приложу как там изобразить простейший вентиль И-НЕ не используя "стандартные" блоки, да и незачем это, ибо есть готовый билиотечный. Зато я запросто сделаю сумматор или сдвиговый регистр на вентилях и триггерах и оформлю в виде очередного кирпичика.
Тебе позарез нужно без синтаксического сахара расписать устройство именно этого автомата? Ну да, будет немного трудоемко, особенно если учесть, что почти весь синтаксический сахар ЯП C# ты тут и привел в этих строках. Нечестно, ибо такой же "синтаксический сахар" можно ввести в блок-схемы, типа "iterate" как разновидность цикла for и "yield value" как разновидность блока окончания.
В итоге можно представить как-то так:
(Статическую структуру рисую в символах здесь, ибо и так понятно как графически будет)
В предполагаемой системе синтаксического сахара можно будет налепить хоть вагон, ибо в качестве параметризируемых кирпичиков должны оседать как отдельные блоки кода, так и целые компоненты: http://www.mathworks.com/cmsimages/sl_librarybrowser_wl_7289.gif
S>То, как вы восприняли мечты Анонима, можно вживую наблюдать в любой скада-системе моложе 15 лет.
Я имел ввиду системы чуть постарше Не суть важно. Уже есть мощнейшие системы моделирования, которые практически то что надо делают, только в узко-специализированной области.
S>Элементарные соображения здравого смысла приводят нас к пониманию того, что аналогичные средства программирования до сих пор не очень-то применяются в мейнстриме не потому, что их невозможно написать, а потому, что выхлоп будет невысоким.
Скорее потому, что народ НЕ обучен действовать по-другому. Математики как-то очень легко лепят блоки и компоненты в MathCad и simulink. Там весьма симпатично итеративность и декларативность сочетается (в MathCad лучше, ИХМО). Там, где нехватает декларативности — дописывают немного связующего императивного кода и оформляют в виде очередного декларативного кирпича.
Я считаю, что эти системы не были распространены еще и потому, что им не хватало тонны уже готовых кирпичей, совместимых друг с другом. С выходом дотнета эта причина нивелировалась. Возможно к этой теме опять вернутся.
S>В нишевых областях визуальное программирование вполне рулит — вон можно глянуть в редакторы Workflow в BizTalk или Workflow Foundation Framework.
Весьма слабые визуальные редакторы ты привел, извини. И возможности языка UML я вообще всерьез не рассматриваю для подобных нужд.
S>Но надо понимать, что никто не ожидает столь же визуального программирования элементов этой картинки.
Хм. У тебя недостаточно информации, чтобы делать такие выводы, ИМХО.
S>Не работает сие.
Работает в современных системах моделирования. С Matlab, LabView и т.д. тоже рекомендую поиграть. У них изначально постепенно текстовая система постепенно от версии к версии приобретает визуальные возможности. Они пошли по пути связи с Java когда-то именно затем, чтобы поиметь сразу тонны готовых "кирпичей".
Вот демка, там еще тонны: http://www.mathworks.com/products/demos/matlab/algorithmdevelopment/algorithmdevelopment_viewlet_swf.html
И что удивительно — MatLab развивают спецы в основном далекие от программирования, что сказывается на GUI и на всяких мелочах (всегда этим страдал).
S>Вот нарисуйте полное графическое представление приведенного мной метода Filter, ужаснитесь и убедитесь.
нарисовал, но не ужаснулся.
Тем более, что настаиваю на дуальном представлении и редактировании, как на наиболее удобном способе. Самое трудное — это расположить всю ту смесь на экране, выбрать удачное представление и удачные юз-кейзы. MathCad-у более-менее удалось, у MatLab и Simulink получается похуже. Кое-что получилось так же у electronic workbench. Там компоненты цифровой логики могут быть как полностью графическими, так и символьно описанными.
_JK>мой тебе совет устройся на хорошую работу с проффессиональным коллективом, через 2-3 года сильно вырастешь и посмеешься над своей юношеской идеей.
Ну не знаю. Я примерно каждые 5 лет возвращаюсь к этой мысли и провожу "обзор окрестностей" с целью узнать, что нового появилось. Плотно сидеть в визуальных средах разработки и моделирования начал как раз 15 лет назад. Никогда не понимал, почему слабо развиваются подобные среды для обычного ПО. ИМХО от того, что студентам прививают несколько иные, символьно-императивные навыки. А потом читать более-менее сложные схемы оказывается проблемно, ибо привыкли читать горы текста. По мне — подробности схем воспринимаются на порядок быстрее, особенно если постоянно с определенным видом схем работаешь.
V>Мне вообще-то плевать как именно это сделано у вас. Я спросил — вы по быстродейтсвию сравнивать свои алгоритмы в вашей системе с оными в Cache пробовали, прежде чем воротить свое аналогичное?
конкретно с кэш не пробовали, скажу честно, уверен что кэш будет медленней, ибо у нас скорость расчета равна скорости чтения данных с носителя. т.е если для рассчета необходимо зачитать 1гб данных, то рассчет закончится с той же скоростью как и закончится копирование этих данных в /dev/null.
V>Ой страшно. Вон в Java и дотнет уже дофига, вообще-то глобально обобщили, десятки и сотни тысяч типов по частоиспользуемым сборкам раскиданы, и прекрасно народ пользуется, ибо малость каталогизированно.
ну да конечно а потом все программерские форумы превращаются в сообщения -"братэллы не подскажете где взять бесплатный компонент для Delphi/Builder/MegaSystem который Hello World на экран выводит?"
хотя написание такой функциональности которая требуется занимает не то, что время через которое ты найдешь свой компонент, а то время которое потребовалось для написание такой мессаги в форум.
_JK>>есть очень много специализированных областей программирование которых абсолютно не похоже на создание формочек из того что я сказал выше. V>Диктую большими буквами — этих областей очень мало. Можешь попытаться их прямо здесь перечислить. Не стесняйся, фантазируй, будет интересно прикинуть их уникальность
что их очень мало это твое мнение все их перечислить просто невозможно,
просто сдается мне что для тех задач корорые ты себе представляешь как главные в области программирования ничего не надо делать давно уже есть готовые движки для интернет магазинов, порталов, и прочей фигни, для решения таких задач не нужны программисты достаточно взять движок и правильно данные в базу залить.
НЕ НАДО РЕШАТЬ ДАВНО РЕШЕННЫЕ ЗАДАЧИ!
PS: вижу что обсуждение перешло совсем не в ту сторону поэтому не считаю целесообразным и далее выступать в роли Кассандры и открывать глаза людям которые совсем не хотят ничего знать, поэтому считаю далее продолжать разговор в этой ветке бессмысленным, на том и заканчиваю.
... << RSDN@Home 1.1.4 @@subversion >>
Re[5]: Как вам задумка, а?
От:
Аноним
Дата:
12.10.06 13:14
Оценка:
Для тех, кто в танке, объясняю: добавление одного оператора в графической среде займет в среднем около 2-5 секунд (надо как минимум найти курсором этот оператор и перетащить его обратно). Это время будет постоянно увеличиваться из-за износа мышки, у которой не больше пяти кнопок. В то же время набор этого оператора на клавиатуре займет не более секунды, кроме того, у клавиатуры больше срок работы, так как у нее больше клавиш. Таким образом, скорость работы в графической среде только понизится.
Кроме того, не выдерживают критики и цели данного проекта.
Цитата:
Цель 1: абстракция от кода на каком-либо языке
Цель 2: отсутствие ошибок компиляции
Цель 3: устранение многих логических ошибок, таких как разорванные связи
Цель 4: более быстрая разработка приложений
1) Эта среда сама создаст язык — графический язык, язык меню, который тоже надо будет учить. Кроме того, в любом случае основ программирования (циклы, ветвления и т.п.) эта система не изменит. Кроме того, не ясно, чем плохи какие-либо языки, и почему от кода на них нужно абстрагироваться.
2) Ох, если бы все ошибки в программах были ошибками компиляции... На олимпиадах по программированию за ошибки компиляции даже не начисляются штрафные попытки.
3) А что такое разорванные связи? В программах (обычных) этих самых связей нет, так что если их и можно где-либо разорвать, то только в голове. А если в голове не все в порядке, то ничего не поможет.
4) см вступление
BlackTigerAP смотрел твою ссылку и ссылку на codeproject смотрел мне не очень понравилось.
p.s. если процесс программирования будет состоять только лишь из банального перетаскивания кубиков, ромбиков, шариков и не будет требовать мозговой активности, а превратится в рутину, то я сменю профессию
Mastering .NET doesn`t make you a geek
It makes you a geek worthy of a raise
>>если процесс программирования будет состоять только лишь из банального перетаскивания кубиков, ромбиков, шариков и не будет требовать мозговой активности, а превратится в рутину
Если процесс перестанет быть творческим, то можно спокойно отдать все эти действия на откуп самой машине... Я думаю, ты понимаешь, к чему это приведет.
>>Если процесс перестанет быть творческим, то можно спокойно отдать все эти действия на откуп самой машине... Я думаю, ты понимаешь, к чему это приведет.
Mastering .NET doesn`t make you a geek
It makes you a geek worthy of a raise
Визуальное проектирование в электроники это только один шаг в создание реально работающей системы. В любой серьезной системе есть микроконтроллер для которого надо писать программу и тут уже нет никакой визуализации, повезет если язык будет С, а не ASM.
Mastering .NET doesn`t make you a geek
It makes you a geek worthy of a raise
Здравствуйте, _JoKe_, Вы писали:
V>>Мне вообще-то плевать как именно это сделано у вас. Я спросил — вы по быстродейтсвию сравнивать свои алгоритмы в вашей системе с оными в Cache пробовали, прежде чем воротить свое аналогичное?
_JK>конкретно с кэш не пробовали, скажу честно, уверен что кэш будет медленней, ибо у нас скорость расчета равна скорости чтения данных с носителя. т.е если для рассчета необходимо зачитать 1гб данных, то рассчет закончится с той же скоростью как и закончится копирование этих данных в /dev/null.
Все зависит от того, как вы эти данные храните. Преимущество обработки на стороне базы в том, что не надо тянуть эти данные в другой процесс и хост. И не говори, что вы храните гиги данных просто в файлах.
V>>Ой страшно. Вон в Java и дотнет уже дофига, вообще-то глобально обобщили, десятки и сотни тысяч типов по частоиспользуемым сборкам раскиданы, и прекрасно народ пользуется, ибо малость каталогизированно. _JK>ну да конечно а потом все программерские форумы превращаются в сообщения -"братэллы не подскажете где взять бесплатный компонент для Delphi/Builder/MegaSystem который Hello World на экран выводит?" _JK>хотя написание такой функциональности которая требуется занимает не то, что время через которое ты найдешь свой компонент, а то время которое потребовалось для написание такой мессаги в форум.
Ты всерьез веришь, что эта проблема порождена улучшением ср-в разработки? Отнюдь. Проблема существует из-за реального сильнейшего дефицита программистов. Почему их дефицит? Да потому что все делают одно и то же, но каждый — свое неповторимое.
Как только программист перестанет быть дефицитом, эти брателлы первыми отсохнут, не переживай.
_JK>что их очень мало это твое мнение все их перечислить просто невозможно, _JK>просто сдается мне что для тех задач корорые ты себе представляешь как главные в области программирования ничего не надо делать давно уже есть готовые движки для интернет магазинов, порталов, и прочей фигни, для решения таких задач не нужны программисты достаточно взять движок и правильно данные в базу залить.
Если ты обратил внимание, то я упирал больше на middle-ware, а это немного не то, что ты озвучил. Это — наработанные способы решения типовых мелочей. Магазин из них строится, хотя сам может быть блоком, разумеется. Насчет "залить в базу" — это не для красного словца, надеюсь понимаешь? Большинство классов приложений так или иначе обрабатывают данные, и базы -это пока безальтернативный способ надежного их хранения и более-менее быстрой массовой обработки. (свой пример с Ораклом и вашим императивным алгоритмом не приводи, насколько я понял, у вас там всего несколько отчетов так строятся, для сравнени — в средней ERP разновидностей отчетов более тысячи). И тем не менее, тонны рукописной работы до сих пор в ORM наблюдается. Почти в любом топике здесь, где кто-либо показывает пример удачной кодогенерации по шаблонам, по базам, автор срывает самые бурные апплодисменты зала. Поневоле призадумаешься, как же так выходит-то, что самая востребованная вещь (судя по реакции) как-то сбоку, неинтегрированно, жутко узкоспециализированно и вообще, сто раз подумаешь, а стоит ли связываться.
_JK>PS: вижу что обсуждение перешло совсем не в ту сторону поэтому не считаю целесообразным и далее выступать в роли Кассандры и открывать глаза людям которые совсем не хотят ничего знать, поэтому считаю далее продолжать разговор в этой ветке бессмысленным, на том и заканчиваю.
Если бы тут были оценки за самоуверенность, ты бы сейчас получил заслуженные 3 балла.
1.1.4 stable rev. 510
