Есть очень интересная задумка, призванная серьёзно облегчить жизнь программистам всего мира.
Просьба, высказаться "за" или "против". Ну и так просто мнения пишите.
Итак по порядку:
Тип: объектно-ориентированная среда разработки
Платформа: .NET
Компилятор: встроенный C#
Цель 1*: абстракция от кода на каком-либо языке
Цель 2**: отсутствие ошибок компиляции
Цель 3***: устранение многих логических ошибок, таких как разорванные связи
Цель 4*: более быстрая разработка приложений
Результат: исполняемый образ .NET
* достигается за счёт сбора программы не из исходного кода, а из предопределённых элементов
часть элементов является элементами алгоритма (циклы, условия, вызов метода и т.п.), но другая (бОльшая) часть является более высокоуровневыми элементами, которые реализуют в себе несколько других того же или более низкого уровня.
** достигается за счёт того, что исходный код, который будет скомпилирован, пишется не программистом, а генерируется ядром среды на основе структуры программы, заданной программистом.
понятно, что этот код всегда будет правильным.
*** перед компиляцией и генерацией кода, структура приложения, собранная программистом из преопределённых элементов, будет проверяться на валидность и на бессмысленость.
поскольку среда является объектно-ориентированной, это значит, что в ней все элементы (класс, структура, метод, цикл и т.д.) в ядре представленны объектами.
например, если мы имеем метод method1, в котором есть инструкция вызова метода method2, то инструкция передставлена объектом, имеющим ссылку на method2, т.о. если программист впоследствии изменит имя метода method2 на method13, то никакой ошибки компиляции не будет, т.к. в инструкции сидит ссылка и инструкция, когда генерирует код, берёт имя метода по ссылке и оно оказывается method13.
это всего лишь один пример, хотя на самом деле такая схема построения программ имеет много других преимуществ.
Самое главное — не надо будет тратить время на строчки кода. Потому что есть много готовых элементов, и программу можно составлять даже мышкой.
Эта среда планируется в будущем как если не замена, то серьёзная альтернатива Visual Studio.
Кстати, модель кода (языка) будет содержать все элементы языка C# (for, foreach, is, as, switch, if, int, bool, и другие), так что перейти на эту среду смогут все те, кто уже знаком с C# или хотя бы с платформой .NET.
Если есть вопросы — задавайте.
А теперь критику и мнения в студию!
Re[4]: Как вам задумка, а?
От:
Аноним
Дата:
19.09.06 15:08
Оценка:
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, <Аноним>, Вы писали:
А>>Самого языка C# достаточно для написания ***любых*** программ. Вы не сможете мне привести как пример ничего, что я не смог бы написать на C#.
AVK>То же самое касается, к примеру, ilasm. Так зачем тогда C#?
Ладно, короче, тут видимо чушь уже понеслась уже в этой теме...
Ждите бета-версию.
Думаю, тогда вы по-другому заговорите.
Re: Как вам задумка, а?
От:
Аноним
Дата:
15.09.06 14:29
Оценка:
Два мнения уже есть.
Оба человека до конца не поняли, что это будет.
Один из них даже начал прикалываться. Про грузинов что-то рассказывать...
Интересно было бы услышать ещё мнения.
Может быть найдутся люди, мыслящие в одном со мной направлении.
И ещё.
Если вы не будете использовать мою среду разработки, это не значит что её не будут использовать ваши конкуренты.
Каждый выберет, то что, удобней и то, на чём быстрее.
Re[8]: Как вам задумка, а?
От:
Аноним
Дата:
07.10.06 12:53
Оценка:
Здравствуйте, LiteX, Вы писали:
LX>Еще вопрос. если вас двое, то как вы договариваетесь что и как нужно делать?
Типо, ноу-хау...
Да на самом деле всё просто: каждый пишет относительно независимые вещи. Скажем, я даю ему задание написать такой-то визуальный компонет GUI, например, наглядно представляющий структуру проекта в моей среде. Для этого я даю ему урезанный вариант ядра с теми классами, интерфейсами и т.д., которые реально понадобятся ему, чтобы извлечь нужную информацию об этой самой структуре. И всё. После того, как он заканчивает конкретный компонент, я свожу его и все остальные компонеты воедино в главное окно или ещё куда там надо и прикручиваю ядро, ресурсы и т.д.
Хм. Это удобно, чёрт возьми, и мне нравиться работать именно так. Человеку необязательно понимать, зачем нужен этот компонент или вон тот. Я говорю ему, что должно быть, и он пишет.
LX>если не на пальцах, то можете выложить документик в котором прописаны требования, возможности, ...
В общем, товарищу Анониму стоит поработать хоть раз с Class Designer, ну тем, что вместе с его Visual Studio 2005 Professional Edition идет. Типа представь несложную изолированную часть проекта... Дюжина классов, пара-тройка интерфейсов, в общей сложности штук сто методов, свойств и событий. Попробуй набросать такую структуру из кода (как все привыкли делать в Visual Studio 2003 и ранее), а потом то же самое из Class Designer. Теперь еще попробуй все это дело задокументировать. Сам сегодня увлекался и следил за производительностью. Пример (в красках):
* Нужно документировать свойство. Если пишем руками, то: нажимает три раза слеш (секунда в худшем случае), пишем комментарий и вставляем теги при помощи Intellisense. Если действуем из Class Designer. Позиционируемся на окно Properties, позиционируемся на строчку Summary, позиционируемся на кнопку "...", нажимаем ее, позиционируемся на текстовое поле Summary, вбиваем туда подсказку без помощи Intellisense, позиционируемся на кнопку Ok, нажимаем кнопку Ok. Ну как? Думаешь, сколько времени займет overhead? А ты попробуй, ты же у нас на слово не веришь.
* Нужно унаследовать класс от интерфейса. Если действуем из кода. Переводим курсор за имя класса. Одна секунда. Нажимаем двоеточие и вбиваем имя интерфейса с помощью Intellisense. Еще секунда. Ну две. Наводим курсор на интерфейс, жмем в меню Implement interface. Еще две секунды. Итого 5 (пять) секунд. Далее мы пытаемся проделать то же самое из Class Designer. Позиционируеся на Toolbox . Одна секунда. Позиционируемся за кнопку Inheritance и нажимаем ее. Еще секунда. Теперь позиционируемся на класс. Три секунды, потому что его необходимо еще где-то найти визуально (а вдруг он у нас за экран вылез, тогда еще и покрутить лифты). Далее мы зажимаем левую кнопку мыши и тащим к интерфейсу, на визуальное отыскание которого уходит еще секунды три + время на перетасивание указателя на тело интерфейса. Дельту сам посчитаешь? Сюда еще добавим субъективную скорость, которая играет очень важную роль при оценке юзабилити и удобство при работе. А с клавиатуры лично мне все эти вещи производить куда как комфортнее... Хотя бы потому, что физически менее затратно. Что проще: пальцами клавиши давить, или мышь по всему столу таскать и постоянно переносить одну руку с мыши на клаву? А мне, как любителю работать с ноута, так и вообще мрак.
Описал бы и дальше, но времени жалко. Class Designer хорош только для визуального представления и мелкой правки. Аноним просто мелко плавал еще...
Здравствуйте, Sinclair, Вы писали:
А>>1. задача — написать цикл foreach и пробежаться таким образом по элементам коллекции, при этом если элемент коллекции < 0, то удалить его А>>2. решение на C# (пишется в блокноте ): А>>
S>Ну, для пущей педантичности приведем более "правильное" решение(приведенный код нарушает мое внутреннее эстетическое чувство, кроме того, его быстродействие на больших словарях просто отвратительно):
S>
S>List<int> keys = new List<int>(idict.Keys);
S>foreach (int key in keys)
S> if (idict[key] < 0)
S> idict.Remove(key);
S>
Опять генерики. Ну нету их в .NET 1.1. Не-ту!!! А я не могу сидеть в Visual Studio 2005 — не та мощность у моего ПК. Это кстати, ещё один момент (не самый главный, правда), который останавливает меня от введения в свою среду генериков и других ненужных наворотов.
S>Начинаем докапываться: S>1. Как выглядит это дерево? Скриншот плиз. Пока что я вижу по-прежнему текст, и никакого ухода от строчек кода не произошло.
GUI ещё не рабочее. Представьте себе элемент TreeView, у которого в узлах — вот эти строчки. Т.е. приведённые строчки сгенерированны ядром среды, а не программистом! Программист только задал параметры.
S>2. А что, выбирать сами операции уже не нужно? Откуда среда знает, что нужно именно foreach, if, и call?
Нет, почему же, ещё нужно. Но достаточно выбрать скажем элемент foreach из списка доступных инструкций и натравить его на на что-то, что поддерживает IEnumerable — вот инструкция готова (придётся указать только тип элементов, в нашем случае — int).
S>3. Как именно происходит выбор этих параметров? Особенно первого параметра для foreach — там как бы бесконечное пространство вариантов.
Это программист сам указывает из списка. Только кто сказал, что там бесконечное множество вариантов? Это множество ограниченно типами загруженных сборок + примитивами, и всё.
S>Так что давайте поподробнее — прямо в элементарных действиях. Типа "правый клик, выбираем New>, ждем ~50 секунд, пока система подгрузит список доступных операций, ...
Кстати, список доступных операций грузится при загрузке среды за ~10 секунд (иногда даже меньше).
В принципе, будет так как вы и сказали. Только не правый клик, а выбор в боковой панели из красивого такого списка (точнее это тоже будет дерево, группированное по категориям инструкций, например: элементарные инструкции, окна, файловая система, сокеты, консоль и т.д.).
Далее появляется окно свойств выбранной инструкции, где можно указать параметры для конкретной инструкции (для if — условие, для for — первое значение, условие выхода, значение инкремента и т.п.).
А>>Вы заметили о чём нужно было позаботится в первом случае? О том, что при изменении коллекции, енумерацию необходимо перезапускать, иначе — исключение. У меня об этом заботится не нужно. Об этом знает генератор кода. S>Откуда он это знает? Как он отличает idict.Remove от Console.WriteLn?
Да потому что я заложил в него это!
А>>Вообще структура проще при манипулировании. S>Пока что этого не видно. В следуюшем письме я обещаю вставить фрагмент реального кода, и мы посмотрим, насколько
Вы не поняли! Я говорю при манипулировании!!! Т.е. при изменении параметров инструкций, имён (клавишей F2), и т.д. и т.п. Понимаете, о чём я? Это же всё автонастраиваемые объекты! Т.е. я могу взять из приведённого примера скопировать foreach, затем вставить его в другой метод, у которого аргумент — тоже реализует IDictionary и всё, этот же код будет работать в другом методе без исправлений. Это как пример.
Да молодой он еще просто. Энергии и идей много, опыта мало. Решил объять необъятное. Пусть делает, что хочет. Лучший источник опыта — шишка на собственном лбу.
How can men die better than facing fearful odds,
For the ashes of their fathers and the temples of their gods?
_JK>>если думаешь что идея супер гениальная предлагаю простой тест — сделай так как сделал г-н Вирт, когда писал первый паскаль — если не в курсе поясняю — он написал его — ВНИМАНИЕ на ПАСКАЛЕ, и скомпилировал на листике ручкой и мозгами.. А>Вирт упился пива наверно, когда изобретал супер-мега-гига паскаль свой... Убожество.
только эта реплика уже о многом говорит.
историю надо учить молодой человек — паскаль появился в 69 году, еще небыло ни С ни С++ ни толком реализованного в каком либо продукте ООП
и Паскаль был на момент рождения одним из лучших языков. даже сейчас, хотя я и пишу в основном на С подобных языках, мне кажется что когда я 10 лет назад писал на паскале — программы получались более структурными, легко читаемыми и понятными.
код компилируется в промежуточный PCODE и microsoft повторил эту идею в .NET только через 40 ЛЕТ, вообще очень многие идеи .net и современного программирования в целом выданы г-ном Виртом, так что святое — не трож!
_JK>>так вот возникает вопрос если твоя идея такая мега гениальная зачем ты пользуешься допотопными, неудобными средствами для её реализации?? реализуй её в своей СУПЕР среде! и получи все вышеназванные тобой преимущества!!!, а мы посмотрим через сколько времени тебе понадобится чтобы реализовать хотя бы то что ты там, как сам утверждаешь уже набросал на допотопном объектно-омперативном языке...
А>Ты сам понял, что сказал? А>Как я реализую свою идею на том, чего ещё нет?
я то понял. поясняю для тех кто в танке Вирт написал компилятор паскаля на ПАСКАЛЕ, зачем сам скомпилировал по алгоритмам его в машинный код, затем уже скомпилированным собрал опять.
вот и ты возьми сделай первую версию в ней реализуй самое необходимое и собери его сам.
а далее уже на своей системе будешь делать новые фичи и компилировать снова и снова... ведь по твоим словам это в ДЕСЯТКИ РАЗ быстрее и удобнее.
_JK>>а потом сравни сколько усилий тебе потребовалось при первом и втором способе... если будет не стыдно выложешь результаты.... (хотя очень сомнительно что вообще используя твой мегапроект ты не застопоришься через час-два уперевшись в неразрешимую проблему, или закопавшись в обилии стрелочек,квадратиков, и treeview).
А>Когда я закончу проект, мне будет не того, чтобы переписывать его с нуля в своей среде.
не хочется переходить на личности но все таки ответь на такой вопрос
учавствовал ли ты в серьезных проектах вообще? писал ли большие коммерческие программы?
мой тебе совет устройся на хорошую работу с проффессиональным коллективом, через 2-3 года сильно вырастешь и посмеешься над своей юношеской идеей.
... << RSDN@Home 1.1.4 @@subversion >>
Re[4]: Как вам задумка, а?
От:
Аноним
Дата:
05.10.06 11:37
Оценка:
Здравствуйте, _JoKe_, Вы писали:
_JK>мой тебе совет устройся на хорошую работу с проффессиональным коллективом, через 2-3 года сильно вырастешь и посмеешься над своей юношеской идеей.
Моя идея далеко не юношеская, а вполне серьёзная.
Ну я же говорю, вас и других никто не заставляет работать в моей среде. Просто вы сами перейдёте на неё, оценив все удобства.
А>Оба человека до конца не поняли, что это будет. А>Один из них даже начал прикалываться. Про грузинов что-то рассказывать...
Возможно ты просто непонятно объясняешь.
А>Интересно было бы услышать ещё мнения. А>Может быть найдутся люди, мыслящие в одном со мной направлении.
Найдутся, скорее всего. Я видел несколько попыток реализовать автопостроение программы по некой диаграмме. И видел, чем они заканчиваются. В большинстве случаев мало-мальски сложный алгоритм гораздо удобней обрабатывать и представлять в виде текста. Впрочем, я знаю одну узкоспециализированную программу, где проще задавать исходные данные в виде диаграммы, а уж по этой диаграмме строится исходник на требуемом языке. По крайней мере, автор утверждает, что ему проще Если пришлешь какой-нибудь контакт, я готов отправить его автору.
А>Если вы не будете использовать мою среду разработки, это не значит что её не будут использовать ваши конкуренты. А>Каждый выберет, то что, удобней и то, на чём быстрее.
Здорово! Значит некоторым количеством конкурентов у нас станет меньше
Re[4]: Как вам задумка, а?
От:
Аноним
Дата:
15.09.06 13:42
Оценка:
Здравствуйте, AndrewVK, Вы писали:
AVK>О, начинается. Давай все же предположим, что суть я понял, и не будем искать проблему во мне, ОК?
А почему вы все набросились на меня с такой злостью? как будто я сволочь здесь какая-то... Я ведь всего лишь преложил обсудить свой проект. Так что, остыньте, ребята, валидольчику там примите, и разговаривайте мирно и конкретно.
Если вы не разделяете моих точек зрения, это не значит, что у вас есть право там разговаривать со мной.
А>> Это *не* есть огромная библиотека с кучей заранее написанных функций. А>>Сами алгоритмы программист пишет сам. Это *среда разработки*. Понимаете?
AVK>Не понимаю. Компоненты тоже программист может писать сам.
Мне сложно сформулировать... правда, сложно... я взялся за такой сложный и большой проект, а не могу даже объяснить в чём его преимущества, т.е. я-то понимаю их, а объяснить их так, чтобы было понятно и доступно, мне сложно...
А>>Ну судите сами:
А>>1. каждый элемент будь то метод, класс, делегат, инструкция или ещё что, является объектом. над объектом мы можем производить любые действия, которые позволяет ядро, а именно А>> копировать А>> перемещать А>> клонировать А>> вставлять ссылку, и дополнять новыми компонентами А>> редактировать в отдельном окне, или в окне редактора родителя (класса, например) А>> создавать шаблоны (скажем, преопределённые классы), и добавлять ссылки на них в программу, а затем наворачивать на них другие компоненты (например, методы) А>> при чём, всё это один щёлчком мышки
AVK>Зачем все это?
Ну это же элементарно! Чтобы скопировать/переместить например класс из одного места в другое (например, из одной сборки в другую), нужно в VS скопировать/вырезать соответствующий текст, далее создать файл, вставить туда этот текст, а потом ещё и искать по всему коду, что нужно исправить, чтобы ни один метод/свойство/поле не ссылался на этот класс и т.п.
Здесь же программист сразу видит (по нажатию одной кнопки) некую такую сводную таблицу, в которой написано, что где нужно изменить, где может быть потенциальная проблема и т.д., а некоторые вещи генератор кода исправляет сам.
далее — шаблоны.
вы что, не понимаете, насколько это мощно? объясняю.
допустим, есть класс.
в нём есть методы, свойства и т.п. теперь допустим мы хотим сделать похожий класс такой, чтобы в нём были отдельные (не все) методы первого класса и при этом чтобы изменения, внесённые в эти методы в первом классе, были актуальны и во втором классе.
как это сделать в VS? никак.
А>>далее все объекты, которые ссылаются на другие например по имени, (для примера, событие типа такого-то делегата), если мы изменим имя делегата, то на событие это не повлияет это никак, также это не повлияет на объекты типа этого делегата, потому что они ссылаются на объект делегат.
AVK>Автоматизированный рефакторинг эту задачу в современных средах решает без проблем, оставляя код человекочитаемым.
вы понимаете, что с моей концепцией не надо в данной случае ни рефакторинга, ни чего-то ещё.
всё автоматически!
А>>2. никакого кода! понимаете? ни-ка-ко-го! AVK>От того, что ты код представишь в графическом виде, или еще как, он кодом быть не перестанет.
можно это воспринимать как угодно, но с графическим представлением работать удобнее в 1000 раз.
А>>3. много предопределённых элементов А>>называйте это "заранее написанными функциями, методами", как хотите, всё это будет неверно, потому что это нечто большее. А>>если сказать очень упрощённо, это — предопределённые куски кода, но! вставляемые не в одно конкретное место в исходном коде, а разные, а именно в те, где они требуются! понятно?
AVK>Нет. Чем это отличается от компонентов?
А вы ещё не поняли??? тогда я уж и не знаю как объяснить...
вы понимаете, что компоненты — это статические элементы, а я говорю о динамической вставке нужных элементов так, чтобы они работали с поправкой на уже готовый код и не глючили.
А>> т.е. если есть какая-то подзадача и её решение требует вставки кусков кода в разные места скажем класса, или вообще в разные классы, то это и будет сделано! одним нажатие мышки. AVK>Ага. Автоматизированный copy&paste. Чем плох CnP объяснять нужно?
Вы всё таки не поняли.
ЭТО НЕ АВТОМАТИЗИРОВАННЫЙ COPYPASTE.
это вставка кусочков кода туда, где они нужны в данном коде
А>>4. более высокая скорость написания (не проектирования, а именно написания) программ по сравнению с тем же Visual Studio, т.к. сколько бы снипплетов или ещё чего она не содержала, от написания строчек кода программисту никуда не уйти. AVK>За счет чего?
за счёт всей моей концепции и всего того, что изложено выше.
А>>5. никаких ошибок компиляции, и автоматическое устранение некоторых логических ошибок на этапе генерации кода AVK>Это не есть достоинство, скорее недостаток.
Здравствуйте, <Аноним>, Вы писали:
AVK>>О, начинается. Давай все же предположим, что суть я понял, и не будем искать проблему во мне, ОК?
А>А почему вы все набросились на меня с такой злостью?
Где ты в момем исходном сообщении увидел злость? Там был единственный, абсолютно нейтральный вопрос. То что тебя он злит, так это твои проблемы.
А> как будто я сволочь здесь какая-то... Я ведь всего лишь преложил обсудить свой проект. Так что, остыньте, ребята, валидольчику там примите, и разговаривайте мирно и конкретно.Если вы не разделяете моих точек зрения, это не значит, что у вас есть право там разговаривать со мной.
Здесь такое не прокатывает. Если будешь хамить, то общение быстро закончится.
AVK>>Не понимаю. Компоненты тоже программист может писать сам.
А>Мне сложно сформулировать... правда, сложно... я взялся за такой сложный и большой проект, а не могу даже объяснить в чём его преимущества, т.е. я-то понимаю их, а объяснить их так, чтобы было понятно и доступно, мне сложно...
Я тебе скажу одну важную вещь — если даже ты сам не можешь объяснить, что ты хочешь, значит у тебя в голове полный сумбур и прежде всего тебе этот сумбур надо устранить. Пока не будет хоть какой то ясности, ничего путного из твоего проекта не выйдет.
AVK>>Зачем все это?
А>Ну это же элементарно! Чтобы скопировать/переместить например класс из одного места в другое (например, из одной сборки в другую), нужно в VS скопировать/вырезать соответствующий текст, далее создать файл, вставить туда этот текст, а потом ещё и искать по всему коду, что нужно исправить, чтобы ни один метод/свойство/поле не ссылался на этот класс и т.п.
Ужас какой. Только все это неправда. Мне например для этого достаточно нажать на имени класса в любом месте кнопочку F6.
А>Здесь же программист сразу видит (по нажатию одной кнопки) некую такую сводную таблицу, в которой написано, что где нужно изменить, где может быть потенциальная проблема и т.д., а некоторые вещи генератор кода исправляет сам.
Ага. И таблички такие VS 2005 тоже умеет строить.
А>далее — шаблоны. А>вы что, не понимаете, насколько это мощно?
Как я могу понять насколько это мощно, если я не знаю о чем ты вобще ведешь речь? Если о шаблонах классов, то в .NET есть дженерики. Если о неких кусках кода с подстановками, то в студии для того есть code snippets.
А> объясняю. допустим, есть класс. А>в нём есть методы, свойства и т.п. теперь допустим мы хотим сделать похожий класс такой, чтобы в нём были отдельные (не все) методы первого класса и при этом чтобы изменения, внесённые в эти методы в первом классе, были актуальны и во втором классе. А>как это сделать в VS? никак.
Почему ж никак? Берешь, выделяешь базовый класс и вперед. Наследование называется. Зачем наследование заменять на Copy&Paste?
AVK>>Автоматизированный рефакторинг эту задачу в современных средах решает без проблем, оставляя код человекочитаемым.
А>вы понимаете, что с моей концепцией не надо в данной случае ни рефакторинга, ни чего-то ещё. А>всё автоматически!
Это автоматически и есть рефакторинг. А как он реализуется, дело десятое. Главное, что для C# он уже реализован.
А>>>2. никакого кода! понимаете? ни-ка-ко-го! AVK>>От того, что ты код представишь в графическом виде, или еще как, он кодом быть не перестанет.
А>можно это воспринимать как угодно, но с графическим представлением работать удобнее в 1000 раз.
Очень спорно. Впрочем, попробуй взять кусок более менее сложного кода, и представь его графически, и мы посмотрим.
Опять же, если уж очень хочется графически, то welcome to class diagrams.
Видтшь ли, твоя идея с графически-бинарным представлением ох как не нова. Самая известная реинкарнация — UML. Только вот на практике оказалось, что текстовое все же удобнее.
А>>>если сказать очень упрощённо, это — предопределённые куски кода, но! вставляемые не в одно конкретное место в исходном коде, а разные, а именно в те, где они требуются! понятно?
AVK>>Нет. Чем это отличается от компонентов?
А>А вы ещё не поняли???
Нет. Ты и не объяснял ничего. Одни лозунги.
А>вы понимаете, что компоненты — это статические элементы,
Конечно же это не так. Весь дизайн-тайм компонентов это чистая динамика.
А> а я говорю о динамической вставке нужных элементов так, чтобы они работали с поправкой на уже готовый код и не глючили.
А вот теперь давай думать, как обеспечить согласование контрактов максимально контроллируемо. Я, к примеру, знаю несколько попыток это сделать. А ты? Что ты слышал про автоматическое доказательство корректности? Spec#?
А>>> т.е. если есть какая-то подзадача и её решение требует вставки кусков кода в разные места скажем класса, или вообще в разные классы, то это и будет сделано! одним нажатие мышки. AVK>>Ага. Автоматизированный copy&paste. Чем плох CnP объяснять нужно?
А>Вы всё таки не поняли. А>ЭТО НЕ АВТОМАТИЗИРОВАННЫЙ COPYPASTE.
Это именно он и есть. При нормальном написании кода нет нужды копировать куда то куски кода. Я, к примеру, даже code snippets не пользуюсь, что уж говорить о более крупных блоках? В современных языках средств реюза кода более чем достаточно.
А>это вставка кусочков кода туда, где они нужны в данном коде
Давай пример что ли приведи.
А>за счёт всей моей концепции и всего того, что изложено выше.
Здравствуйте, Марк, Вы писали:
А>>Оба человека до конца не поняли, что это будет. А>>Один из них даже начал прикалываться. Про грузинов что-то рассказывать... М>Возможно ты просто непонятно объясняешь.
Возможно. Уж как умею.
А>>Интересно было бы услышать ещё мнения. А>>Может быть найдутся люди, мыслящие в одном со мной направлении. М>Найдутся, скорее всего. Я видел несколько попыток реализовать автопостроение программы по некой диаграмме. И видел, чем они заканчиваются. В большинстве случаев мало-мальски сложный алгоритм гораздо удобней обрабатывать и представлять в виде текста. Впрочем, я знаю одну узкоспециализированную программу, где проще задавать исходные данные в виде диаграммы, а уж по этой диаграмме строится исходник на требуемом языке. По крайней мере, автор утверждает, что ему проще Если пришлешь какой-нибудь контакт, я готов отправить его автору.
Я не уверен, что у того человека точно такая же мысль, как и у меня, но что-то похожее вроде...
Здравствуйте, <Аноним>, Вы писали:
А>Проект мой начался ещё год назад. Начался с того, что мне лично ***надоело набирать эти грёбанные строчки кода***!!! Поэтому я решил сделать некую среду, которая бы позволяла в глаза не видеть этот код, а просто делать программу мышкой по кусочкам. Ну вводить с клавы только там... имена для понятия смысла объекта, да параметры объектов...
А>Вот вам не надоело набирать код? А>В моей среде не только "диаграммы", как вы их называете, будут, но также графически будут представлены и сами тела методов.
Ты бы скиншотов или концептуальных рисунков каких-нибудь выложил. Может проще было бы обеснять.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Re[12]: Как вам задумка, а?
От:
Аноним
Дата:
17.09.06 10:05
Оценка:
Здравствуйте, Дьяченко Александр, Вы писали:
А>>Ну вы и облажались.
ДА>Почему? Потому что открыто признал что убил полгода непонятно на что, или потому что назвал это маеньем дурью?
Потому что назвали мой проект маением дурью.
Вот этот проект можно назвать маянием дурью или вот этот.
Я же занимаюсь серьёзной вещью, которой я думаю будут пользоваться программисты во всём мире, т.к. она делается именно для и ради них, чтобы облегчить им жизнь.
А>>Я-то в отличие от вас не дурью маюсь и не брежу, а пишу это. Ядро почти готово.
ДА>Ну во-первых это было давно (я еще в школе учился), во-вторых задача была практически обратная той которую решаешь ты (исходник на сильно покусаном Basic перевести в блок-схему с возможностью исполнения всего этого дела (вобщем простенькие алгоритмы демонстрировать (сортировки всякие и т.д.)))
Понятно. Кстати, сначала я тоже думал написать что-то вроде интерпретатора, основанного на .NET Reflection, т.е. чтобы по структуре, заданной программистом, стролся IL-код и далее выполнялся через рефлексию.
ДА>ЗЫ. Повторюсь удачи тебе вдруг действительно что-то получится.
Вот с этого надо было и начинать. Нельзя говорить типа "это хорошо", а вот "это — совсем ацтой", нужно говорить что-то типа "может из-за этого и выйдет толк", или "я не вижу в этом смысла потому-то и потому-то...".
Удача мне действительно понадобиться когда рекламой займусь.
Re[5]: Как вам задумка, а?
От:
Аноним
Дата:
25.09.06 05:07
Оценка:
Твой вопрос, вообще, даже не технического плана, а, скорее, филосовского. Наш мир не состоит из блоков, хотя это и может так показаться. Наш мир фрактальный. А мы — порождение нашего мира со всеми вытекающими. Если бы мир был блочным, то всё кругом состояло бы из кубов и квадратов, как самых приспособленных для сборки. Никаких закругленностей и угловатостей, за исключением прямых углов. Ан нет, куда не посмотри — фракталы, самый неблочный тип, самый порядочно-беспорядочный. Вроде бы посмотришь — вот он блок! А присмотришься по-ближе — ё моё... Короче, фракталы рулят этим миром, а не блоки. Любая попытка унификации и блокоизации этого мира обречена на провал изначально.
How can men die better than facing fearful odds,
For the ashes of their fathers and the temples of their gods?
Здравствуйте, <Аноним>, Вы писали:
Не удержался. Уж очень мне жалко всех тех, кто упорно пытается честно идти на поводу у автора постинга и заниматься конструктивной критикой непонятно чего.
Уважаемый аноним, на ваш запрос невозможно дать никакого полезного ответа. Вы тщательно написали о том, чего НЕ будет в вашей мегасреде. Очень хорошо. А что будет взамен? Про это ничего по существу не сказано — какие-то туманные намеки.
Поэтому все обсуждение сводится к:
— критике выбрасывания полезных, по мнению народа, вещей (строчек кода)
— критике того, как критик представляет себе реализацию Ваших туманных намеков.
Поэтому Вам я крайне рекомендую просто взять и запостить пару скриншотов. Ведь для этого достаточно MS Paint и свободного вечера, не так ли? Вон МС уже вовсю рассказывает о том, как мы будем кодить через 13 лет: http://www.codeproject.com/useritems/Visual_Studio_2020.asp
Покажите мне, как будет выглядеть вот этот простенький код в вашей мегасреде:
public static IEnumerable<T> Filter<T>(IEnumerable<T> source, Predicate<T> predicate)
{
foreach(T item in source)
if (predicate(item))
yield return item;
}
Тогда я, к примеру, смогу задать еще парочку уточняющих вопросов.
Вообще, для справки: когда вы предлагаете решение некой задачи, для его обоснования нужно сделать буквально следующее:
1. Описать типичную задачу, которую предполагается решать
2. Описать типичные шаги, которые выполняются пользователем в существущем подходе (или нескольких подходах)
3. Описать типичные шаги, которые надо будет выполнить в вашем решении.
Если речь идет о повышении удобства, то необходимо и достаточно доказать или хотя бы обосновать сокращение количества элементарных действий в п.3. по сравнению с п.2.
А пока это все голые лозунги на уровне "повысим благосостояние граждан" и "долой задолженности перед бюджетниками". Без конкретных механизмов это бессмысленно обсуждать.
Программисты — народ недоверчивый. Глупо надеяться, что они поведутся на голый маркетинг.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
теперь по существу.... очень похоже на очень молодого программиста, который просто не умеет на клавиатуре работать, и его очень утруждает одним пальцем набирать по слову в минуту.
теперь доказательсто бредовости.
если думаешь что идея супер гениальная предлагаю простой тест — сделай так как сделал г-н Вирт, когда писал первый паскаль — если не в курсе поясняю — он написал его — ВНИМАНИЕ на ПАСКАЛЕ, и скомпилировал на листике ручкой и мозгами..
так вот возникает вопрос если твоя идея такая мега гениальная зачем ты пользуешься допотопными, неудобными средствами для её реализации?? реализуй её в своей СУПЕР среде! и получи все вышеназванные тобой преимущества!!!, а мы посмотрим через сколько времени тебе понадобится чтобы реализовать хотя бы то что ты там, как сам утверждаешь уже набросал на допотопном объектно-омперативном языке...
а потом сравни сколько усилий тебе потребовалось при первом и втором способе... если будет не стыдно выложешь результаты.... (хотя очень сомнительно что вообще используя твой мегапроект ты не застопоришься через час-два уперевшись в неразрешимую проблему, или закопавшись в обилии стрелочек,квадратиков, и treeview).
... << RSDN@Home 1.1.4 @@subversion >>
Re[8]: Как вам задумка, а?
От:
Аноним
Дата:
07.10.06 12:53
Оценка:
Здравствуйте, LiteX, Вы писали:
LX>Аноним почему бы вам не представиться?
V>А вот и зря. Идея эта не нова и даже тут неоднократно обсуждалась. Ведь электронщики давно делают предложенное, правда? V>Сделать т.н. "ядро" для рендеринга модели в готовый код не так уж и сложно. Ты бы лучше покумекал насчет того, как это будет выглядеть. Для примера показал бы процесс графического (юзером в GUI) составления хотя бы несложных алгоритмов, или ORM данных из базы на некую иерархию объектов. V>(Очень рекомендую много посидеть в различных сложных CAD-системах для электронщиков, может это подскажет тебе что-нить )
хе... только электронщики начали понимать сложность диаграмм для описания ЛОГИКИ, и придумали для себя язык VHDL + ППЛМ и его эмуляторы( что то типа компилятора и отладчика в терминах программиста), после чего создание электронной логики вышло на качественно новый уровень , так что пока мир идет к описанию на языках автор идет в обратном направлени не желая ничего слушать.
... << RSDN@Home 1.1.4 @@subversion >>
Re[5]: Как вам задумка, а?
От:
Аноним
Дата:
12.10.06 13:14
Оценка:
Для тех, кто в танке, объясняю: добавление одного оператора в графической среде займет в среднем около 2-5 секунд (надо как минимум найти курсором этот оператор и перетащить его обратно). Это время будет постоянно увеличиваться из-за износа мышки, у которой не больше пяти кнопок. В то же время набор этого оператора на клавиатуре займет не более секунды, кроме того, у клавиатуры больше срок работы, так как у нее больше клавиш. Таким образом, скорость работы в графической среде только понизится.
Кроме того, не выдерживают критики и цели данного проекта.
Цитата:
Цель 1: абстракция от кода на каком-либо языке
Цель 2: отсутствие ошибок компиляции
Цель 3: устранение многих логических ошибок, таких как разорванные связи
Цель 4: более быстрая разработка приложений
1) Эта среда сама создаст язык — графический язык, язык меню, который тоже надо будет учить. Кроме того, в любом случае основ программирования (циклы, ветвления и т.п.) эта система не изменит. Кроме того, не ясно, чем плохи какие-либо языки, и почему от кода на них нужно абстрагироваться.
2) Ох, если бы все ошибки в программах были ошибками компиляции... На олимпиадах по программированию за ошибки компиляции даже не начисляются штрафные попытки.
3) А что такое разорванные связи? В программах (обычных) этих самых связей нет, так что если их и можно где-либо разорвать, то только в голове. А если в голове не все в порядке, то ничего не поможет.
4) см вступление
Здравствуйте, vdimas, Вы писали:
V>И я даже знаю, где проходит граница м/у этими "не везде". Всё, что можно описать декларативно, теоретически вполне поддается визуальному дизайну и параметризации. Я считаю, что процент императивного пока что неоправданно высок. Я бы оставил в большинстве случаев только формулы какие-нить.
Так вот, возвращаясь к исходному сообщению топика — очевидно, что нужно сначала обдумать, что и как должно быть декларативно, а уж потом бросаться делать супер-пупер продукт.
Здравствуйте, 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
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Исправлен "рисунок"
От:
Аноним
Дата:
17.10.06 03:35
Оценка:
Всё. Достал этот бред. Отписываюсь от "темы"...
How can men die better than facing fearful odds,
For the ashes of their fathers and the temples of their gods?
Здравствуйте, Аноним, Вы писали:
А>А теперь критику и мнения в студию!
в кратце?! БРЕД. чем все выше изложенное отличается от присловутой концепции RAD development? а ничем.
потому все выше описанное не что иное, как вырожденный вариант c#, с большим количеством написанных кусков кода...
юзер будет у нас тупым и будет собирать из кубиков код... концепция стара. вариантов реализации тысячи.
продвинуть идею до чего-то большого еще пока никто не смог. потому что надо концептуальное улучшение, а не на уровне давайте сделаем кнопочку красевее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, <Аноним>, Вы писали:
А>>Если есть вопросы — задавайте.
AVK>Чем это отличается от компонентов?
Нет, вы видимо не очень поняли суть. Это *не* есть огромная библиотека с кучей заранее написанных функций.
Сами алгоритмы программист пишет сам. Это *среда разработки*. Понимаете?
Ну судите сами:
1. каждый элемент будь то метод, класс, делегат, инструкция или ещё что, является объектом. над объектом мы можем производить любые действия, которые позволяет ядро, а именно
копировать
перемещать
клонировать
вставлять ссылку, и дополнять новыми компонентами
редактировать в отдельном окне, или в окне редактора родителя (класса, например)
создавать шаблоны (скажем, преопределённые классы), и добавлять ссылки на них в программу, а затем наворачивать на них другие компоненты (например, методы)
при чём, всё это один щёлчком мышки
далее все объекты, которые ссылаются на другие например по имени, (для примера, событие типа такого-то делегата), если мы изменим имя делегата, то на событие это не повлияет это никак, также это не повлияет на объекты типа этого делегата, потому что они ссылаются на объект делегат.
2. никакого кода! понимаете? ни-ка-ко-го! ни на языке C#, ни на C++, ни на VB .NET, ни на Java...
хотя возможность вставлять свои куски кода на C# планируется в версии наверно в 3ей...
3. много предопределённых элементов
называйте это "заранее написанными функциями, методами", как хотите, всё это будет неверно, потому что это нечто большее.
если сказать очень упрощённо, это — предопределённые куски кода, но! вставляемые не в одно конкретное место в исходном коде, а разные, а именно в те, где они требуются! понятно? т.е. если есть какая-то подзадача и её решение требует вставки кусков кода в разные места скажем класса, или вообще в разные классы, то это и будет сделано! одним нажатие мышки.
4. более высокая скорость написания (не проектирования, а именно написания) программ по сравнению с тем же Visual Studio, т.к. сколько бы снипплетов или ещё чего она не содержала, от написания строчек кода программисту никуда не уйти.
5. никаких ошибок компиляции, и автоматическое устранение некоторых логических ошибок на этапе генерации кода
Здравствуйте, Аноним, Вы писали:
А>Нет, вы видимо не очень поняли суть. Это *не* есть огромная библиотека с кучей заранее написанных функций. А>Сами алгоритмы программист пишет сам. Это *среда разработки*. Понимаете?
А теперь подумай сам. Количество операций возможных над объектом определяется бизнесс логикой...
аналогичную задумку пробовали реализовать при помощи технологии COM макрософты, но как видим технология перешла в новую стадию... и уже мало чем напоминающую COM.
Здравствуйте, <Аноним>, Вы писали:
AVK>>Чем это отличается от компонентов?
А>Нет, вы видимо не очень поняли суть.
О, начинается. Давай все же предположим, что суть я понял, и не будем искать проблему во мне, ОК?
А> Это *не* есть огромная библиотека с кучей заранее написанных функций. А>Сами алгоритмы программист пишет сам. Это *среда разработки*. Понимаете?
Не понимаю. Компоненты тоже программист может писать сам.
А>Ну судите сами:
А>1. каждый элемент будь то метод, класс, делегат, инструкция или ещё что, является объектом. над объектом мы можем производить любые действия, которые позволяет ядро, а именно А> копировать А> перемещать А> клонировать А> вставлять ссылку, и дополнять новыми компонентами А> редактировать в отдельном окне, или в окне редактора родителя (класса, например) А> создавать шаблоны (скажем, преопределённые классы), и добавлять ссылки на них в программу, а затем наворачивать на них другие компоненты (например, методы) А> при чём, всё это один щёлчком мышки
Зачем все это?
А>далее все объекты, которые ссылаются на другие например по имени, (для примера, событие типа такого-то делегата), если мы изменим имя делегата, то на событие это не повлияет это никак, также это не повлияет на объекты типа этого делегата, потому что они ссылаются на объект делегат.
Автоматизированный рефакторинг эту задачу в современных средах решает без проблем, оставляя код человекочитаемым.
А>2. никакого кода! понимаете? ни-ка-ко-го!
От того, что ты код представишь в графическом виде, или еще как, он кодом быть не перестанет.
А>3. много предопределённых элементов А>называйте это "заранее написанными функциями, методами", как хотите, всё это будет неверно, потому что это нечто большее. А>если сказать очень упрощённо, это — предопределённые куски кода, но! вставляемые не в одно конкретное место в исходном коде, а разные, а именно в те, где они требуются! понятно?
Нет. Чем это отличается от компонентов?
А> т.е. если есть какая-то подзадача и её решение требует вставки кусков кода в разные места скажем класса, или вообще в разные классы, то это и будет сделано! одним нажатие мышки.
Ага. Автоматизированный copy&paste. Чем плох CnP объяснять нужно?
А>4. более высокая скорость написания (не проектирования, а именно написания) программ по сравнению с тем же Visual Studio, т.к. сколько бы снипплетов или ещё чего она не содержала, от написания строчек кода программисту никуда не уйти.
За счет чего?
А>5. никаких ошибок компиляции, и автоматическое устранение некоторых логических ошибок на этапе генерации кода
Это не есть достоинство, скорее недостаток.
А>6. плюс все классы платформы .NET
Да, это большой плюс. Особенно по сравнению с C#.
Вобщем, пока что полный сумбур. Куча лозунгов и никаких реальных путей их достижения.
Здравствуйте, alku, Вы писали:
A>Здравствуйте, Аноним, Вы писали:
А>>А теперь критику и мнения в студию!
A>в кратце?! БРЕД. чем все выше изложенное отличается от присловутой концепции RAD development? а ничем. A>потому все выше описанное не что иное, как вырожденный вариант c#, с большим количеством написанных кусков кода...
вы не поняли: здесь реализована абстракция от языка, никакого C#, вообще никакого языка! и никаких больших кусков кода!
A>юзер будет у нас тупым и будет собирать из кубиков код... концепция стара. вариантов реализации тысячи.
дайте хоть бы одну ссылку
и вообще, если такое уже реализованно, то почему же люди до сих пор программируют в Visual Studio, а не собирают код из кусочков?!!
A>продвинуть идею до чего-то большого еще пока никто не смог. потому что надо концептуальное улучшение, а не на уровне давайте сделаем кнопочку красевее.
моя концепция уже должна быть понятна, она заключается в 2х вещах:
1. сбор программы из кусочков (только часть этих кусочков — элементы C#, только часть!)
2. полуинтеллектуальный генератор кода (планируется в версии 4ой, уже есть мысли)
A>мое имхо — бред
ну да, чего-то похожего я и ожидал
а вообще, чем больше мнений, тем лучше
Здравствуйте, Аноним, Вы писали:
А>вы не поняли: здесь реализована абстракция от языка, никакого C#, вообще никакого языка! и никаких больших кусков кода!
A>>юзер будет у нас тупым и будет собирать из кубиков код... концепция стара. вариантов реализации тысячи.
А>дайте хоть бы одну ссылку А>и вообще, если такое уже реализованно, то почему же люди до сих пор программируют в Visual Studio, а не собирают код из кусочков?!!
чем выше абстракция, тем меньше шансов на качественное и быстрое исполнение и тем больше издержек абстракции.
кроче в двух словах:
1) читай книгу "анти-патерны". Слишком много абстракции тоже плохо.
2) примеры: в школе не учил диаграмки для рисования алгоритмов?! теперь есть такое и у макрософта Workflow Framework (правда задачи слегка посложнее решает), UML диаграммы — как язык программирования?!
Re[4]: Как вам задумка, а?
От:
Аноним
Дата:
15.09.06 13:44
Оценка:
Здравствуйте, alku, Вы писали:
A>2) примеры: в школе не учил диаграмки для рисования алгоритмов?! теперь есть такое и у макрософта Workflow Framework (правда задачи слегка посложнее решает), UML диаграммы — как язык программирования?!
про UML знаю
"UML диаграммы — как язык программирования?!" — а чем плохо????
Здравствуйте, <Аноним>, Вы писали:
А>Если вы не будете использовать мою среду разработки, это не значит что её не будут использовать ваши конкуренты. А>Каждый выберет, то что, удобней и то, на чём быстрее.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, alku, Вы писали:
A>>2) примеры: в школе не учил диаграмки для рисования алгоритмов?! теперь есть такое и у макрософта Workflow Framework (правда задачи слегка посложнее решает), UML диаграммы — как язык программирования?!
А>про UML знаю А>"UML диаграммы — как язык программирования?!" — а чем плохо????
ну что-ж если ты не могешь сформировать мысли и концепции более точно, то давай тогда будем тебя "пинать" в нужную сторону.
Я так понимаю ты ожидал brain storm твоей идеи?! ну большинство эээ откинуло сразу по причине наличия опыта
и так давай попробуем чтобы ты логически сам пришел к такому выводу.
и так за основу возьмем язык С#. какими графическими символами ты хочешь отображать елементарные операции, аля циклы и условия?
Каким способом ты собираешся отображать методы? классы? взаимодействие классов?
для статистики: средний класс имеет в районе 20 методов, 10-15 пропертей, 10 ивентов... размер класса в среднем до 1000 строк.
для описание механизма работы 1 ивента в UML надо нарисовать 2-4 диаграммы и то они не полностью опишут ситуации, которые возможны. (диаграмма состояний, activity, collobaration, sequence). 1 проперти — 2-3 диаграммы, метода — 2-3 диаграммы. итого: 20 * 2 (методы) + 10*2 (проперти) + 10*3 (ивенты) == 90 диаграмм.
время написания класса 1-2 дня... создание 90 диаграмм — 2-3 недели
еще доказательства нужны?!
Re[6]: Как вам задумка, а?
От:
Аноним
Дата:
16.09.06 13:14
Оценка:
Здравствуйте, ArtDenis, Вы писали:
AD>Здравствуйте, <Аноним>, Вы писали:
А>>"UML диаграммы — как язык программирования?!" — а чем плохо????
AD>Потому, что они в основном предназначены для решения проблем проектирования, а не реализации.
А это не важно. В конце концов, никто не мешает мне совместить два в одном.
Re[6]: Как вам задумка, а?
От:
Аноним
Дата:
16.09.06 13:29
Оценка:
Здравствуйте, alku, Вы писали:
A>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте, alku, Вы писали:
A>>>2) примеры: в школе не учил диаграмки для рисования алгоритмов?! теперь есть такое и у макрософта Workflow Framework (правда задачи слегка посложнее решает), UML диаграммы — как язык программирования?!
А>>про UML знаю А>>"UML диаграммы — как язык программирования?!" — а чем плохо????
A>ну что-ж если ты не могешь сформировать мысли и концепции более точно, то давай тогда будем тебя "пинать" в нужную сторону. A>Я так понимаю ты ожидал brain storm твоей идеи?! ну большинство эээ откинуло сразу по причине наличия опыта
Нет, как раз я свою идею понимаю полностью. Другое дело, что у меня не получается внятно объяснить её вам... Но от этого идея хуже не станет.
A>и так за основу возьмем язык С#. какими графическими символами ты хочешь отображать елементарные операции, аля циклы и условия? A>Каким способом ты собираешся отображать методы? классы? взаимодействие классов?
Какими символами? хм... странный вопрос, вообще-то символами латинского и русского алфавитов.
Сам объект, скажем, класс, будет представлен в виде дерева (типа TreeView), у которого узлы — методы, свойства и другие компоненты. В свою очередь, узел "метод" будет являтся поддеревом, у которого узлы — это и есть инструкции, будь то for, if, switch, call или более высокоуровневые команды.
И для начала я не ставлю задачу написать средство проектирования, с меня пока будет достаточно средства программирования. А там посмотрим, если будут заявки — сделаю.
A>для статистики: средний класс имеет в районе 20 методов, 10-15 пропертей, 10 ивентов... размер класса в среднем до 1000 строк.
A>для описание механизма работы 1 ивента в UML надо нарисовать 2-4 диаграммы и то они не полностью опишут ситуации, которые возможны. (диаграмма состояний, activity, collobaration, sequence). 1 проперти — 2-3 диаграммы, метода — 2-3 диаграммы. итого: 20 * 2 (методы) + 10*2 (проперти) + 10*3 (ивенты) == 90 диаграмм.
A>время написания класса 1-2 дня... создание 90 диаграмм — 2-3 недели
Я ничего из этого не понял. Что вы хотели этим сказать?
Проект мой начался ещё год назад. Начался с того, что мне лично ***надоело набирать эти грёбанные строчки кода***!!! Поэтому я решил сделать некую среду, которая бы позволяла в глаза не видеть этот код, а просто делать программу мышкой по кусочкам. Ну вводить с клавы только там... имена для понятия смысла объекта, да параметры объектов...
Вот вам не надоело набирать код?
В моей среде не только "диаграммы", как вы их называете, будут, но также графически будут представлены и сами тела методов.
Re[8]: Как вам задумка, а?
От:
Аноним
Дата:
16.09.06 14:47
Оценка:
Здравствуйте, Дьяченко Александр, Вы писали:
ДА>Здравствуйте, <Аноним>, Вы писали:
А>>Проект мой начался ещё год назад. Начался с того, что мне лично ***надоело набирать эти грёбанные строчки кода***!!! Поэтому я решил сделать некую среду, которая бы позволяла в глаза не видеть этот код, а просто делать программу мышкой по кусочкам. Ну вводить с клавы только там... имена для понятия смысла объекта, да параметры объектов...
А>>Вот вам не надоело набирать код? А>>В моей среде не только "диаграммы", как вы их называете, будут, но также графически будут представлены и сами тела методов.
ДА>Ты бы скиншотов или концептуальных рисунков каких-нибудь выложил. Может проще было бы обеснять.
Ну пока там и смотреть нечего. Я сейчас ядром среды занимаюсь пока... А GUI на таком уровне, что...
Несколько позже я обязательно выложу и презентаху, и картинки, да и саму прогу. Первая версия будет бесплатной, чтобы как можно больше народу смогли ознакомиться с ней.
Здравствуйте, AndrewVK, Вы писали:
ДА>>Ты бы скиншотов или концептуальных рисунков каких-нибудь выложил. Может проще было бы обеснять. AVK>Бесполезно. Намного проще делать умный вид и считать других дураками .
Если сильно хочется пусть старается. Может выйдет что-нибудь что можно можно переделать в что-нибудь полезное .
AVK>P.S. Лет 12 назад я тоже бредил такими идеями.
Давно. Я тоже лет 8-9 назад полгодига маелся дурью где-то в этом же раёне, только развернутым на 180 градусов.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Re[10]: Как вам задумка, а?
От:
Аноним
Дата:
17.09.06 09:16
Оценка:
Здравствуйте, Дьяченко Александр, Вы писали:
ДА>Здравствуйте, AndrewVK, Вы писали:
ДА>>>Ты бы скиншотов или концептуальных рисунков каких-нибудь выложил. Может проще было бы обеснять. AVK>>Бесполезно. Намного проще делать умный вид и считать других дураками .
ДА>Если сильно хочется пусть старается. Может выйдет что-нибудь что можно можно переделать в что-нибудь полезное .
AVK>>P.S. Лет 12 назад я тоже бредил такими идеями.
ДА>Давно. Я тоже лет 8-9 назад полгодига маелся дурью где-то в этом же раёне, только развернутым на 180 градусов.
Ну вы и облажались.
Я-то в отличие от вас не дурью маюсь и не брежу, а пишу это. Ядро почти готово.
Здравствуйте, <Аноним>, Вы писали:
ДА>>>>Ты бы скиншотов или концептуальных рисунков каких-нибудь выложил. Может проще было бы обеснять. AVK>>>Бесполезно. Намного проще делать умный вид и считать других дураками . ДА>>Если сильно хочется пусть старается. Может выйдет что-нибудь что можно можно переделать в что-нибудь полезное . AVK>>>P.S. Лет 12 назад я тоже бредил такими идеями. ДА>>Давно. Я тоже лет 8-9 назад полгодига маелся дурью где-то в этом же раёне, только развернутым на 180 градусов.
А>Ну вы и облажались.
Почему? Потому что открыто признал что убил полгода непонятно на что, или потому что назвал это маеньем дурью?
А>Я-то в отличие от вас не дурью маюсь и не брежу, а пишу это. Ядро почти готово.
Ну во-первых это было давно (я еще в школе учился), во-вторых задача была практически обратная той которую решаешь ты (исходник на сильно покусаном Basic перевести в блок-схему с возможностью исполнения всего этого дела (вобщем простенькие алгоритмы демонстрировать (сортировки всякие и т.д.)))
ЗЫ. Повторюсь удачи тебе вдруг действительно что-то получится.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Re[13]: Как вам задумка, а?
От:
Аноним
Дата:
17.09.06 10:09
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Дьяченко Александр, Вы писали:
А>>>Ну вы и облажались.
ДА>>Почему? Потому что открыто признал что убил полгода непонятно на что, или потому что назвал это маеньем дурью?
А>Потому что назвали мой проект маением дурью. А>Вот этот проект можно назвать маянием дурью или вот этот.
Я имел в виду этот и этот проекты, например. И ещё вот этот тоже ахинея.
Здравствуйте, <Аноним>, Вы писали:
А>>>Ну вы и облажались. ДА>>Почему? Потому что открыто признал что убил полгода непонятно на что, или потому что назвал это маеньем дурью? А>Потому что назвали мой проект маением дурью.
Ну вобще-то маением дурью я назвал свои потраченные полгода. Если ты принял это на свой счет, то извеняюсь.
А>Вот этот проект можно назвать маянием дурью или вот этот.
Позволю себе не согласится. То что эти проекты нельзя назвать революционными это наверняка (может кроме RSharp-а). Помоему маеньем дурью любой проект может назвать только его автор (группа авторов), т.к. проект может быть исследовательским, тренировочным или еще каким-нибудь важным автору по какой-либо причине. Поэтому я как автор могу смело назвать потраченными эти полгода практически зря.
А>Я же занимаюсь серьёзной вещью, которой я думаю будут пользоваться программисты во всём мире, т.к. она делается именно для и ради них, чтобы облегчить им жизнь.
Если честно положа руку на сердце, то я в это не верю (и AndrewVK похоже тоже не верит). Но если ты веришь в то что делаешь и при этом не мешаешь жить другим, то это исключительно твое дело. Поэтому воизбежание открытия очередного фронта holywar предлагаю свернуть эту тему. Вот результаты будут обращайся попробывать и высказать свои мысли я пожалуй возьмусь. А то опять получается какое-то обсуждение сферических коней в вакууме.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Re[14]: Как вам задумка, а?
От:
Аноним
Дата:
17.09.06 12:48
Оценка:
Здравствуйте, Дьяченко Александр, Вы писали:
А>>Я же занимаюсь серьёзной вещью, которой я думаю будут пользоваться программисты во всём мире, т.к. она делается именно для и ради них, чтобы облегчить им жизнь.
ДА>Если честно положа руку на сердце, то я в это не верю (и AndrewVK похоже тоже не верит). Но если ты веришь в то что делаешь и при этом не мешаешь жить другим, то это исключительно твое дело. Поэтому воизбежание открытия очередного фронта holywar предлагаю свернуть эту тему. Вот результаты будут обращайся попробывать и высказать свои мысли я пожалуй возьмусь. А то опять получается какое-то обсуждение сферических коней в вакууме.
Вы в это не верите наверно потому что этим занимаюсь я, а не Micro$oft.
Когда будет готов первый дистрибутив, я выложу его в сеть и здесь кину ссылку.
Все желающие будут тестить, знакомиться и так далее.
Здравствуйте, <Аноним>, Вы писали:
А>Вы в это не верите наверно потому что этим занимаюсь я, а не Micro$oft.
Если совсем честно, то Microsoft я бы тоже не поверил.
А>Когда будет готов первый дистрибутив, я выложу его в сеть и здесь кину ссылку. А>Все желающие будут тестить, знакомиться и так далее.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Дьяченко Александр, Вы писали:
А>>>Я же занимаюсь серьёзной вещью, которой я думаю будут пользоваться программисты во всём мире, т.к. она делается именно для и ради них, чтобы облегчить им жизнь.
ДА>>Если честно положа руку на сердце, то я в это не верю (и AndrewVK похоже тоже не верит...
please attach me too
А>Вы в это не верите наверно потому что этим занимаюсь я, а не Micro$oft. А>Когда будет готов первый дистрибутив, я выложу его в сеть и здесь кину ссылку. А>Все желающие будут тестить, знакомиться и так далее.
короче товарищь, нечего показывать — тогда плиз заминай писать глобальные идеи, если нет чего-то что можно пощюпать, то все это будут воспринимать, как очередную не удавшуюся шутку...
кстати вопросик:
— возьмем Visio замечательный продукт для построения диаграмм.. + огромные возможности расширения.
— берем твой случай: почему тебе не хотелось воспользоваться Visio как GUI, а путем расширений Visio сделать завязку на код?!...
или как обычно: этот код плох тем что не я его писал?!
BTW если нет четко сформированных требований к продукту — то это не продукт, а бред.
Ms, кстати, всегда начинают с четкой спецификации, что они хотят сделать (для примера иди на Microsoft Research).
Этим и отличается MS от Васи Пупкина села Олуево, потому что они практикуют правильные подходы к созданию продуктов.
Re[15]: Как вам задумка, а?
От:
Аноним
Дата:
18.09.06 07:40
Оценка:
Кстати, UML для кодирования сейчас разрабатывается, преимущественно российской группой. Посмотрим, что выйдет. Но переход к коду от UML-представлений — давно уже стандартная функциональность соответствующих продуктов.
Здравствуйте, alku, Вы писали:
A>короче товарищь, нечего показывать — тогда плиз заминай писать глобальные идеи, если нет чего-то что можно пощюпать, то все это будут воспринимать, как очередную не удавшуюся шутку...
Я ведь вообще-то хотел только узнать мнения. А показывать я пока ничего и не должен, ждите.
A>кстати вопросик: A>- возьмем Visio замечательный продукт для построения диаграмм.. + огромные возможности расширения. A>- берем твой случай: почему тебе не хотелось воспользоваться Visio как GUI, а путем расширений Visio сделать завязку на код?!...
A>или как обычно: этот код плох тем что не я его писал?!
Да, именно так
A>BTW если нет четко сформированных требований к продукту — то это не продукт, а бред. A>Ms, кстати, всегда начинают с четкой спецификации, что они хотят сделать (для примера иди на Microsoft Research). A>Этим и отличается MS от Васи Пупкина села Олуево, потому что они практикуют правильные подходы к созданию продуктов.
Услышал об этом впервые от вас, хотя про другие продукты Лютца знаю и даже пользуюсь ими (.NET Reflector, .NET Resourcer).
Посмотрел я презентахи эти, и не понял вот чего: а где ***полная абстракция от кода*** ??? Как я понял из презентаций, текст программы всё же пишется на каком-то ещё более абстрагированном языке, нежели C#. Что по моему мнению, не есть выход.
Самого языка C# достаточно для написания ***любых*** программ. Вы не сможете мне привести как пример ничего, что я не смог бы написать на C#. Поэтому не надо придумывать никаких новых языков! Поэтому я против Nemerle, R# и т.п. Нужно повышать уровень удобства (а значит и скорости) составления программы, чем я и занимаюсь.
Здравствуйте, <Аноним>, Вы писали:
А>Самого языка C# достаточно для написания ***любых*** программ. Вы не сможете мне привести как пример ничего, что я не смог бы написать на C#.
То же самое касается, к примеру, ilasm. Так зачем тогда C#?
Твоя "задумка" — полный бред, не стоящий и выеденного яйца. Обижаешься? На обиженных воду возят.
Ты не первый, кто возомнил себя гением, а всех остальных — идиотами. Многие пытались "абстрагироваться от кода". Не получилось ни у кого. А проблема даже не в реализации, а глубже — в филосифии.
А где проходит граница между кодом и абстрагированием от него? Вот тут вся ерунда и начинается. Как ты собрался абстрагироваться от, например, динамического присваивания Caption кнопке? И от прочих подобных вещей. Так придется строить абстракции до уровня атомов, кварков и прочих мюзонов. А это уже не абстракция, а самый что ни наесть геморрой.
Твоя "абстракция" реализована в Microsoft Dynamics AX. Что получилось? Да говно (уж извините админы, можете заретушировать, но получилось именно оно). Всё равно от кода отказаться не получилось. Блоки-то можно соединять, таскать их мышкой туда-сюда, только вот сами блоки надо писать кодом. А тут налинается всё тоже поле граблей.
Хотя если тебе нечем больше заняться на работе — флаг в руки. Ты ж с рсдн-а, там переизобретателей велосипедов и "настоящих героев" много. :D :D :D
How can men die better than facing fearful odds,
For the ashes of their fathers and the temples of their gods?
Здравствуйте, уважаемый Аноним!
А>Есть очень интересная задумка, призванная серьёзно облегчить жизнь программистам всего мира.
А>Тип: объектно-ориентированная среда разработки А>Платформа: .NET А>Компилятор: встроенный C# А>Цель 1*: абстракция от кода на каком-либо языке А>Цель 2**: отсутствие ошибок компиляции А>Цель 3***: устранение многих логических ошибок, таких как разорванные связи А>Цель 4*: более быстрая разработка приложений А>Результат: исполняемый образ .NET
А>* достигается за счёт сбора программы не из исходного кода, а из предопределённых элементов
А>** достигается за счёт того, что исходный код, который будет скомпилирован, пишется не программистом, а генерируется ядром среды на основе структуры программы, заданной программистом.
А>Самое главное — не надо будет тратить время на строчки кода. Потому что есть много готовых элементов, и программу можно составлять даже мышкой.
А>Эта среда планируется в будущем как если не замена, то серьёзная альтернатива Visual Studio.
А>А теперь критику и мнения в студию!
В каком-то смысле ваши идеи "носятся в воздухе". Достаточно ясно, что будущее за подходом, в основе которого лежит компоновка программы как некоторого множества стандартных настраиваемых блоков. В принципе, такие вещи как: визуальные компоненты, библиотеки стандартных классов и шаблонов таких классов, COM и CORBA -- уже существенное продвижение в этом направлении. Остается лишь вывести представить все эти вещи на некоем едином абстрактном уровне (некие блоки), представить программу в виде графической схемы (множества таких связанных блоков), продумать механизм трансляции такой схемы в программу. Самая главная проблема, на мой взгляд -- в том, чтобы при трансляции связать стандартные блоки инициализирующим/вызывающим/финализирующим программным кодом. Все остальное достаточно тривиально.
Критики такого подхода, конечно, могут сказать, что в большинстве случаев проще написать программу самому, чем использовать какую-то систему порождения программы с графическим интерфейсом, особенно, если под конкретную задачу к ней придется разрабатывать какие-то свои узкоспециальные блоки. Мне, например, так не кажется. Несколько лет работы программистом породили стойкое отвращение к разработке программного "ширпотреба" на стандартных базах данных и стандартных визуальных компонентах. Просто руки чешутся все это автоматизировать, причем создать какую-нибудь универсальную систему, чтобы можно было ее дополнить при желании, настроив почти на любую предметную область.
Должен сказать, что согласен с Вами почти по всем пунктам и сам работаю в схожем направлении. Один из вариантов системы, схожей с той, о которой Вы пишете, разработан. Система включает: графический редактор схемы программы в виде блоков; транслятор схемы в программу на промежуточном обобщенном языке; транслятор с обобщенного языка на конкретный (C, Pascal). Блоки программы -- по сути порождающие автоматы, работа которых настраивается параметрами блоков. Не буду утверждать, что разрабатывать такие блоки очень легко, не буду утверждать, что использую лучшую модель порождения кода (есть там и ООП, и событийная модель и еще кое-что от имитационного моделирования) и т.п., но система работает. Достаточно грамотно создать блоки один раз и программирование какой-то задачи облегчается в разы.
Отличие моей системы от той, которую хотите построить Вы состоит в том, что я, все-таки не ставил себе задачи ПОЛНОСТЬЮ автоматизировать порождение любых программ. Пока Система создавалась как средство автоматизации программирования в любой предметной области -- для каждой области достаточно разработать систему блоков или, если угодно, классов. По-моему, это несколько более перспективное направление.
Система экспериментальная и применяю я ее в "личных" целях -- для настройки и порождения фрагментов программ численного моделирования экологических процессов. Еще когда-то применял для моделирования манипуляторов роботов -- по кинетической схеме манипулятора генерируются M-скрипты, моделирующие его динамику. Еще раз повторюсь, что сама по себе система универсальная, подключаются лишь разные иерерхии порождающих блоков (классов).
Я затрудняюсь навскидку сказать, пригодна ли моя система для решения в точности всех тех задач, которые поставили Вы. Вероятно, возможно. Но для объективности скажу, что пока в этом направлении работать пока не предполагаю. Если у Вас будет желание, Вы можете со мной связаться, могу прислать скриншоты и немного рассказать о моих технологиях.
Я очень редко заглядываю на этот форум. Все желающие могут связаться со мной по почте:
В.В.Пекунов, pekunov@mail.ru.
Добавлю, что мы с вами -- далеко не единственные, кто работает в этой области. Рекомендую Вам поискать в Интернете работы А.А.Шалыто (хотя бы). Есть еще такая вещь как Rational Rose, если Вы не знакомы с этой системой, то рекомендую познакомиться. Тоже реализуются идеи, очень схожие с Вашими. Еще знаю о работах, где программы пытаются порождать, анализируя текстовое описание задачи на естественном языке. Авторы таких работ утверждают, что обнадеживающие результаты есть.
Re[2]: Как вам задумка, а?
От:
Аноним
Дата:
21.09.06 04:27
Оценка:
Ну что критики, поняли, чем пахнет?!
Полной, глобальной, всемирной автоматизацией!!!
Автор, 5 балофф вам! Спасибо.
Свяжусь с вами обязательно, как только будет время.
Одна только заметка: за основу я взял C#, т.е. у меня нет никакого промежуточного языка.
Т.е. можно сказать о том, что моя среда (первая версия) будет некой графической обёрткой над кодом, позволяющей упростить и ускорить составление кода.
Здравствуйте, <Аноним>, Вы писали:
А> В каком-то смысле ваши идеи "носятся в воздухе".
Носились. Лет 10 назад. Сейчас как то больше интереса к рефакторингу и улучшению текстовых языков.
А>Остается лишь вывести представить все эти вещи на некоем едином абстрактном уровне (некие блоки), представить программу в виде графической схемы (множества таких связанных блоков), продумать механизм трансляции такой схемы в программу.
Все это уже есть. В качестве языка, как правило, используется UML.
AVK>Носились. Лет 10 назад. Сейчас как то больше интереса к рефакторингу и улучшению текстовых языков.
Это очень спорный вопрос. Направление отнюдь не заглохло. Во многих достаточно крупных университетах, где есть приличная кафедра по программированию или смежным областям, ведутся схожие исследования. А уж одиночек-энтузиастов всегда хватает. Ведь идея-то перспективная и не реализованная в полной мере.
Что касается улучшения текстовых языков, то Вы, видимо, имеете в виду традиционные универсальные языки программирования? Что же, может быть я уже немного и поотстал в этой области, но у меня пока складывается впечатление некоторого временного тупика в этой области. Очень мелкие улучшения идут, количественные. Что такого существенно нового появилось в этой области после ООП, шаблонов, компонентного подхода?
А>>Остается лишь вывести представить все эти вещи на некоем едином абстрактном уровне (некие блоки), представить программу в виде графической схемы (множества таких связанных блоков), продумать механизм трансляции такой схемы в программу.
AVK>Все это уже есть. В качестве языка, как правило, используется UML.
Да, конечно. Взять ту же самую систему Rational Rose. Я не имел случая ознакомиться с полной версией этой системы, но, судя по тому, что читал -- без написания фрагментов собственного кода там не обходится. А хотелось бы обойтись. И еще очень спорный вопрос -- насколько удобен UML для построения таких схем. Да, это стандарт. Но отсюда не следует, что необходимо его слепо придерживаться.
Re[3]: Как вам задумка, а?
От:
Аноним
Дата:
21.09.06 09:59
Оценка:
>>Ведь идея-то перспективная и не реализованная в полной мере.
Ржунимагу! Серьёзно. А тебе, гений, не приходило в голову почему за столько 10-тилетий это никому так и не удалось? :D
Ну а ты, типа, самый умный оказался? Ну флаг тебе в руки. Скажи на каком кладбище твоя идея скоро окажется — я ей цветочек принесу.
How can men die better than facing fearful odds,
For the ashes of their fathers and the temples of their gods?
Здравствуйте, <Аноним>, Вы писали:
А> Это очень спорный вопрос. Направление отнюдь не заглохло.
Не заглохло конечно. Но интерес у большинства пропал.
А> Во многих достаточно крупных университетах, где есть приличная кафедра по программированию или смежным областям, ведутся схожие исследования. А уж одиночек-энтузиастов всегда хватает. Ведь идея-то перспективная и не реализованная в полной мере.
Не вижу я перспектив. Пока, по факту, все эти системы ожидаемого эффекта не дали. Зато очень большой эффект дали современные интеллектуальные IDE, снабженные огромным количеством языковых сервисов. По скорости и удобству разработки за IDEA или VS 2005 ни один UML-моделлер не способен угнаться даже в перспективе.
А> Что касается улучшения текстовых языков, то Вы, видимо, имеете в виду традиционные универсальные языки программирования? Что же, может быть я уже немного и поотстал в этой области, но у меня пока складывается впечатление некоторого временного тупика в этой области. Очень мелкие улучшения идут, количественные. Что такого существенно нового появилось в этой области после ООП, шаблонов, компонентного подхода?
Дело не в том, что появилось вобще, дело в том, что попало в мейнстрим.
А> Да, конечно. Взять ту же самую систему Rational Rose. Я не имел случая ознакомиться с полной версией этой системы,
А я имел. И, собственно, ничего такого перспективнго я там не увидел. Сложно, неудобно, медленно.
А> но, судя по тому, что читал -- без написания фрагментов собственного кода там не обходится. А хотелось бы обойтись.
Однако я пока не видел удобного графического способа отображения выражений. Вобще. А удобство блоксхем для отображения императивного алгоритма уже стало притчей воязыцех.
Здравствуйте, Аноним, Вы писали:
А> Здравствуйте, уважаемый Аноним!
А>>Есть очень интересная задумка, призванная серьёзно облегчить жизнь программистам всего мира.
А>>Тип: объектно-ориентированная среда разработки А>>Платформа: .NET А>>Компилятор: встроенный C# А>>Цель 1*: абстракция от кода на каком-либо языке А>>Цель 2**: отсутствие ошибок компиляции А>>Цель 3***: устранение многих логических ошибок, таких как разорванные связи А>>Цель 4*: более быстрая разработка приложений А>>Результат: исполняемый образ .NET
А>>* достигается за счёт сбора программы не из исходного кода, а из предопределённых элементов
А>>** достигается за счёт того, что исходный код, который будет скомпилирован, пишется не программистом, а генерируется ядром среды на основе структуры программы, заданной программистом.
А>>Самое главное — не надо будет тратить время на строчки кода. Потому что есть много готовых элементов, и программу можно составлять даже мышкой.
А>>Эта среда планируется в будущем как если не замена, то серьёзная альтернатива Visual Studio.
А>>А теперь критику и мнения в студию!
Я с Вас понимаю и с Вами согласен.
Но это огромный труд. Мы потратили на свою систему 75 человеколет.
И то сделали ее с испуга, не знали сколько для этого нужно будет сил.
Сейчас, когда мне выделили для начала системы на C# ресурс в 10 человеколет, мне бывает страшно — сколько надо всего делать.
А> В каком-то смысле ваши идеи "носятся в воздухе".
И давно! Мы занимаемся этим уже лет 14.
В начале делали это в ДОС как SCADA систему с названием RCS.
Затем разработали технологию Флора, имеем около 10 портаций(Windows, Linux, Solaris, QNX, x86, x64, SPARC).
Сейчас мы разрабатываем все это для платформы .NET, проект NETree.
А> Должен сказать, что согласен с Вами почти по всем пунктам и сам работаю в схожем направлении. Один из вариантов системы, схожей с той, о которой Вы пишете, разработан.
И с Вами я согласен.
А> Добавлю, что мы с вами -- далеко не единственные, кто работает в этой области.
Все же нас мало!!! Я говорю о тех, кто что-то сделал.
А теперь к некоторым из ALL, кто не верит в нетекстовое программирование.
Можно все сделать красиво, приложения будут создаваться играючи и не только игрушечные, уж поверте.
А теперь к тем из ALL, кто верит и мечтает.
Просто так не сделать, а если и сделать то не продать, даже не продинуть и задаром.
Потому, что это настолько ни на что не похоже, что не все понимаю, а кто понимает, тот боится.
Уж поверте.
Re[3]: Как вам задумка, а?
От:
Аноним
Дата:
21.09.06 15:35
Оценка:
Здравствуйте, Lever, Вы писали:
L>А теперь к некоторым из ALL, кто не верит в нетекстовое программирование. L>Можно все сделать красиво, приложения будут создаваться играючи и не только игрушечные, уж поверте.
L>А теперь к тем из ALL, кто верит и мечтает. L>Просто так не сделать, а если и сделать то не продать, даже не продинуть и задаром. L>Потому, что это настолько ни на что не похоже, что не все понимаю, а кто понимает, тот боится.
L>Уж поверте.
Из вас мистика так и прёт... у-у-у-у-у!... но мне нравится...
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Lever, Вы писали:
А>Из вас мистика так и прёт... у-у-у-у-у!... но мне нравится...
Нет никакой мистики.
Есть опыт реализации объектного метода.
Когда за плечами что-то похожее на Smalltalk (правда, Флора похожа на Smalltalk тем, что они вдвоем ни на что не похожи) по неволе становишься реалистом.
Re[4]: Как вам задумка, а?
От:
Аноним
Дата:
22.09.06 04:47
Оценка:
Просмотрел пост... ну что ту скажешь. Приятно, с одной стороны, наблюдать романтиков. Хочется даже пойти в парк стихи почитать. Блока, например, или Вильяма Блейка. С другой стороны, романтика подобная уже как-то приелась. Работал я над одним проектом несколько лет назад, там руководитель исповедовал какую-то подобную идеологию... была попытка создать систему, которая должна была "облегчить работу программиста" и "максимально ускорить процесс разработки" основывалось все на IDEF3, платформка должна была поспособствовать созданию быстрых и качественных бизнес решений... Чем это все закончилось: получилась некоторая сомнительная поделка, которая не только не ускоряла процесс разработки, но во многом его тормозила и не позволяла удовлетворять желания заказчиков ни по срокам ни по качеству. При всем при том, что команда разработчиков состояла из достаточно талантливых ребят.
Это самый страшный код, который существует во вселенной... запускайте обфускатор.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, <Аноним>, Вы писали:
А>> В каком-то смысле ваши идеи "носятся в воздухе".
AVK>Носились. Лет 10 назад. Сейчас как то больше интереса к рефакторингу и улучшению текстовых языков.
А>>Остается лишь вывести представить все эти вещи на некоем едином абстрактном уровне (некие блоки), представить программу в виде графической схемы (множества таких связанных блоков), продумать механизм трансляции такой схемы в программу.
AVK>Все это уже есть. В качестве языка, как правило, используется UML.
вспомнилось: из последних разработок визуального программирования есть IDE для написания программ для робота.
игрушка новая на западном рынке... запамятовал только как заветься разработка... вроде бы даже Ms ее делают.
это к теме, что не все на UML как на панацею смотрят... ищут пути, но пока явно слабо..
Здравствуйте, alku, Вы писали:
AVK>>Все это уже есть. В качестве языка, как правило, используется UML.
A>это к теме, что не все на UML как на панацею смотрят... ищут пути, но пока явно слабо..
Проблемы с UML начинаются, когда его используют как язык для описания модели, с последующим ее автоматическим построением.
А делать надо с точностью до наоборот.
Строить сразу модель на дереве объектов, использую графические редакторы, которые могут использовать диаграммы UML для конкретных объектов.
А затем можно и показать объектную модель в формате UML.
Как вам задумка, а?
От:
Аноним
Дата:
22.09.06 20:38
Оценка:
Идея автора, это типичный Software Factories + DSL (Domain-Specific Languages).
Стоит глянуть на http://msdn.microsoft.com/vstudio/DSLTools/ не давно вышел очередной релиз инструментария для построения таких решений.
А также посмотреть на книжку "Software Factories" или на худой конец "Generative Programing" (в русском издании "Порождающее програмирование" )
Здравствуйте, BlackTigerAP, Вы писали:
>>>Самого языка C# достаточно для написания ***любых*** программ. Вы не сможете мне привести как пример ничего, что я не смог бы написать на C#
BTA>Ну напиши на C# два метода класса, отличающихся типом возвращаемых значений.
Даже не хотел отвечать сначала. Но решил дать тебе понять, что ты сморозил глупость и своим постом выставил себя идиотом.
Re[4]: Как вам задумка, а?
От:
Аноним
Дата:
24.09.06 09:58
Оценка:
>>Даже не хотел отвечать сначала. Но решил дать тебе понять, что ты сморозил глупость и своим постом выставил себя идиотом.
Ну ничего другого, кроме оскорблений, я от анонима с рсдн-а не ожидал. Посмотри в зеркало.
Напиши еще драйвер какого-нибудь устройства.
How can men die better than facing fearful odds,
For the ashes of their fathers and the temples of their gods?
Откуда у вас столько злости?! Я ведь это чувствую и не могу понять: почему? Я никого не оскорблял. Это вы всё время смешиваете меня с дерьмом, хотя я всего навсего пишу программу, и искрене верю в её необходимость, я не граблю банки, не вырываю у старушек сумки и не мучаю детей.
Чёрт возьми, почему бы не сказать просто: "слушай, по-моему это бесполезно..." или "это бесперспективно, так как не даёт преимуществ...". Но вы же пишете как? Почитайте вот это, например
Хотя если тебе нечем больше заняться на работе — флаг в руки. Ты ж с рсдн-а, там переизобретателей велосипедов и "настоящих героев" много. :D :D :D
Какой ужос! Как жёстко сказано! Какие сгустки отрицательной энергии летят ко мне с экрана монитора!
Или из более ранних постов:
Бесполезно. Намного проще делать умный вид и считать других дураками
Тоже фраза, как будто на мне можно ставить крест, хотя я не самый худший программист и у меня много интересных идей.
Если сильно хочется пусть старается. Может выйдет что-нибудь что можно можно переделать в что-нибудь полезное
Ну а это вообще выдержка из разговора двух бандитов, "крышующих" какую-то фирму.
или как обычно: этот код плох тем что не я его писал?!
Тут опять пытаются показать, что я идиот и не знаю "общепринятых" каких-то вещей. Кстати, я чхать хотел на "общепринятые" вещи.
Где ты в момем исходном сообщении увидел злость? Там был единственный, абсолютно нейтральный вопрос. То что тебя он злит, так это твои проблемы.
Здесь странно только одно: я со всеми общался на Вы. Почему человек перешёл на ты — непонятно.
Здесь такое не прокатывает. Если будешь хамить, то общение быстро закончится.
Так вы хамы, а не я!
Ужас какой. Только все это неправда. Мне например для этого достаточно нажать на имени класса в любом месте кнопочку F6.
Пробовал я нажимать F6 на имени класса и... ничего не произошло. Visual Studio .NET 2003.
Грузины лучше чем армяне. Чем? Чем армяне.
Это был неудачный пример...
То же самое касается, к примеру, ilasm. Так зачем тогда C#?
Не надо передёргивать! И ассемблер и языки высокого уровня одинаково нужны. Но нет необходимости в нескольких языках высокого уровня и тем более нет необходимости в языках сверхвысокого уровня.
Ты не первый, кто возомнил себя гением, а всех остальных — идиотами.
Не правда! Я не считаю себя гением, а других идиотами.
Ну напиши на C# два метода класса, отличающихся типом возвращаемых значений.
Здесь наверно был расчёт на то, что я скажу что-то типа "легко! почему нет?", т.е. на то, что я совсем тупой программист...
Кстати в моей среде я планирую сделать такую возможность во второй версии.
Ну а ты, типа, самый умный оказался? Ну флаг тебе в руки. Скажи на каком кладбище твоя идея скоро окажется — я ей цветочек принесу.
Это просто грубо. И не стоит преждевременно хоронить идею. Любую идею.
Не обязательно отвечать на этот пост, но хотя бы будьте сдержанее! Если хотите сказать что-то язвительное — вы уже переходите в категорию хама в тот момент, когда мысль запостить это приходит вам в голову.
Re[4]: Как вам задумка, а?
От:
Аноним
Дата:
24.09.06 17:28
Оценка:
Здравствуйте, BlackTigerAP, Вы писали:
>>>Ведь идея-то перспективная и не реализованная в полной мере.
BTA>Ржунимагу! Серьёзно. А тебе, гений, не приходило в голову почему за столько 10-тилетий это никому так и не удалось? :D
А Вам не приходило в голову, что если не пробовать реализовать идею, то она и не будет реализована (если, это, конечно, не вечный двигатель)? Многие работают в этом направлении (кстати, очень неглупые люди) и не только у меня кое-что получается. Так что насчет "не удалось" -- не спешите.
BTA>Ну а ты, типа, самый умный оказался? Ну флаг тебе в руки. Скажи на каком кладбище твоя идея скоро окажется — я ей цветочек принесу.
Обычно на хамство переходят, когда по делу возразить нечего.
Re[5]: Как вам задумка, а?
От:
Аноним
Дата:
24.09.06 18:29
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, BlackTigerAP, Вы писали:
>>>>Ведь идея-то перспективная и не реализованная в полной мере.
BTA>>Ржунимагу! Серьёзно. А тебе, гений, не приходило в голову почему за столько 10-тилетий это никому так и не удалось? :D
А> А Вам не приходило в голову, что если не пробовать реализовать идею, то она и не будет реализована (если, это, конечно, не вечный двигатель)? Многие работают в этом направлении (кстати, очень неглупые люди) и не только у меня кое-что получается. Так что насчет "не удалось" -- не спешите.
BTA>>Ну а ты, типа, самый умный оказался? Ну флаг тебе в руки. Скажи на каком кладбище твоя идея скоро окажется — я ей цветочек принесу.
А> Обычно на хамство переходят, когда по делу возразить нечего.
Как же я согласен с вами!
Re[5]: Как вам задумка, а?
От:
Аноним
Дата:
24.09.06 19:46
Оценка:
Уважаемый Аноним.
Как вы уже, наверно, поняли в вашу идею мало кто верит, но вы по прежнему доказываете, что она верна и выведет программирование на новый уровень, почему бы вам просто не выложить в вашу идею в виде готового решения и попросить всех заценить реализацию идеи.
И после этого, думаю, можно 100% будет кто был прав, а кто нет, но пока этого нет весь разговор пустой трёп. Все карты вам в руки.
p.s. Если у вас всё получиться, то респект и уважуха вам , не получится то ....
Злость? Да ни капельки. Не надо путать злость с реализмом и прагматизмом. Есть идеи перспективные и бесперспективные.
Вот посмотри на конструктор ЛЕГО. Почему он не состоит из уже готовых блоков? Да потому что это было бы абсолютно никому не интересно. Да, базовый комплект состоит из более-менее узкоспециальзированных деталей. Но всё равно, чтобы создать что-то более-менее приличное, надо покупать "кирпичи", самые мелкие детали общего назначения. Без этих деталей, сколько ЛЕГО не собирай, всё время вертолет будет получаться. :D
Вот эти "кирпичики" и есть аналог "рукописного кода". Никуда ты от него не денешься. Разве что будут "блоки кода", типа блок "if", "for", "увеличить на единицы" и так далее. Т.е. дробить до атомарных размеров. А вот как раз руками эти блоки проще написать, чем мышкой таскать — быстрее будет (ввод с клавиатуры в 3 раза быстрее, чем ввод мышью, доказано учеными). Так можно скатиться и до блоков вроде "буква А прописная", "буква А заглавная" и тыды :D
Да и вообще. Вынося такую тему на публичное обсуждение, будь готов услышать и болезненные для твоего самомнения мнения. Не умеешь держать критику — не выноси на публику вообще. Если же считаешь, что есть только два мнения — твоё и неправильное, то тут уже никто никому ничем не поможет.
Всё, отписываюсь от темы. РСДНовский флейм ниочем, как всегда.
How can men die better than facing fearful odds,
For the ashes of their fathers and the temples of their gods?
Но! Запретить кто-то кому-то что-то делать никто не может. Хочется? Да, пожалуйста! Наше дело — предупредить, твоё дело — слушать или нет. Получится — хорошо, всем скажешь "вот я был прав, а вы — нет!", а не получится... Кто-то молча головой покачает, кто-то не сдержится и скажет "Вот мы же говорили..." Хочется делать? Пожалуйста! Но не надо ожидать того, что все тебя поддержат и встанут на твою сторону. Твоя идея чужда нашему миру — будь готов ко всему.
How can men die better than facing fearful odds,
For the ashes of their fathers and the temples of their gods?
Здравствуйте, LiteX, Вы писали:
LX>Уважаемый Аноним. LX>Как вы уже, наверно, поняли в вашу идею мало кто верит, но вы по прежнему доказываете, что она верна и выведет программирование на новый уровень, почему бы вам просто не выложить в вашу идею в виде готового решения и попросить всех заценить реализацию идеи. LX>И после этого, думаю, можно 100% будет кто был прав, а кто нет, но пока этого нет весь разговор пустой трёп. Все карты вам в руки.
Я прекрасно понимал всё это. Ещё до того, как я запостил эту тему, все мои знакомые высказывались против, точнее они не понимали идею вообще. Никто из них не сказал, что я изобретаю велосипед! Они просто недопонимали саму идею. Так что я готов к непониманию...
Re[6]: Как вам задумка, а?
От:
Аноним
Дата:
25.09.06 06:40
Оценка:
Здравствуйте, LiteX, Вы писали:
LX>Если не затруднит, напишите пожалуйста драйвер для видеокарты. (видеокарта на ваш вкус). LX>Либо создайте аналог линуховской LILO (программа, которая будет позволять выбирать ОС для загрузки)
Хех, я вообще-то имел в виду прикладное ПО.
Re[2]: Как вам задумка, а?
От:
Аноним
Дата:
25.09.06 07:13
Оценка:
S>Поэтому все обсуждение сводится к: S>- критике выбрасывания полезных, по мнению народа, вещей (строчек кода) S>- критике того, как критик представляет себе реализацию Ваших туманных намеков.
Жаль только, что критики плохо представляют себе мою реализацию. Может быть, потому что я недостаточно внятно её объяснил.
Впрочем, всё то, что сейчас говорится, тоже весьма интересно лично мне.
Кстати мне и только мне судить о полезности всех этих рассуждений, т.к. это именно то, рали чего я запостил эту тему.
S>Вон МС уже вовсю рассказывает о том, как мы будем кодить через 13 лет:
Я думаю, раньше
S>Покажите мне, как будет выглядеть вот этот простенький код в вашей мегасреде: S>
Это у вас "простенький" код? Должен огорчить любителей генериков — в первой версии их не будет. Я думаю, я их не буду поддерживать вообще. Вместо них я лучше сделаю другой механизм, но похожий, не на уровне языка, а на уровне абстрагированной структуры проекта.
S>Вообще, для справки: когда вы предлагаете решение некой задачи, для его обоснования нужно сделать буквально следующее: S>1. Описать типичную задачу, которую предполагается решать S>2. Описать типичные шаги, которые выполняются пользователем в существущем подходе (или нескольких подходах) S>3. Описать типичные шаги, которые надо будет выполнить в вашем решении.
Ну это просто.
1. задача — написать цикл foreach и пробежаться таким образом по элементам коллекции, при этом если элемент коллекции < 0, то удалить его
2. решение на C# (пишется в блокноте ):
START:
foreach (int key in idict.Keys)
{
if (idict [key] < 0)
{
idict.Remove (key);
goto START;
}
}
собственно для этого решения необходимо только набрать эти строчки кода
3. решение в моей среде (типа это дерево вроде TreeView):
<method 5> EnumerateCollection (System.Collections.IDictionary idict) : bool
| // тело метода
-- <instruction 1> foreach {int key, idict.Keys}
| // тело цикла
-- <instruction 1> if {idict [key] < 0}
| // тело условия
-- <instruction 1> idict.Remove {key}
для этого решения достаточно в 2х диалоговых окнах (а в будущем — боковых панелях, так будет удобнее) выбрать параметры 3х операций — foreach, if и call.
Вы заметили о чём нужно было позаботится в первом случае? О том, что при изменении коллекции, енумерацию необходимо перезапускать, иначе — исключение. У меня об этом заботится не нужно. Об этом знает генератор кода.
Здравствуйте, <Аноним>, Вы писали:
А>Жаль только, что критики плохо представляют себе мою реализацию. Может быть, потому что я недостаточно внятно её объяснил.
Совершенно верно. Объясняйте как можно подробнее — иначе нечего критиковать. S>>Вон МС уже вовсю рассказывает о том, как мы будем кодить через 13 лет: А>Я думаю, раньше
На самом деле да. Часть из этих идей будет реализована уже в ближайшие 3-5 лет.
А>Это у вас "простенький" код?
Конечно. Он прекрасно читается, легко пишется, и превосходен в использовании.
А>Должен огорчить любителей генериков — в первой версии их не будет. Я думаю, я их не буду поддерживать вообще. Вместо них я лучше сделаю другой механизм, но похожий, не на уровне языка, а на уровне абстрагированной структуры проекта.
Ха-ха. Ладно, фиг с ними, с генериками.
А>Ну это просто.
А>1. задача — написать цикл foreach и пробежаться таким образом по элементам коллекции, при этом если элемент коллекции < 0, то удалить его А>2. решение на C# (пишется в блокноте ): А>
Ну, для пущей педантичности приведем более "правильное" решение(приведенный код нарушает мое внутреннее эстетическое чувство, кроме того, его быстродействие на больших словарях просто отвратительно):
List<int> keys = new List<int>(idict.Keys);
foreach (int key in keys)
if (idict[key] < 0)
idict.Remove(key);
А>собственно для этого решения необходимо только набрать эти строчки кода
Совершенно верно. Причем среда с Code Completion помогает набирать код, примерно вдвое сокращая количество нажатий на кнопки. А>3. решение в моей среде (типа это дерево вроде TreeView): А>
А><method 5> EnumerateCollection (System.Collections.IDictionary idict) : bool
А>| // тело метода
А>-- <instruction 1> foreach {int key, idict.Keys}
А> | // тело цикла
А> -- <instruction 1> if {idict [key] < 0}
А> | // тело условия
А> -- <instruction 1> idict.Remove {key}
А>
А>для этого решения достаточно в 2х диалоговых окнах (а в будущем — боковых панелях, так будет удобнее) выбрать параметры 3х операций — foreach, if и call.
Начинаем докапываться:
1. Как выглядит это дерево? Скриншот плиз. Пока что я вижу по-прежнему текст, и никакого ухода от строчек кода не произошло.
2. А что, выбирать сами операции уже не нужно? Откуда среда знает, что нужно именно foreach, if, и call?
3. Как именно происходит выбор этих параметров? Особенно первого параметра для foreach — там как бы бесконечное пространство вариантов.
Так что давайте поподробнее — прямо в элементарных действиях. Типа "правый клик, выбираем New>, ждем ~50 секунд, пока система подгрузит список доступных операций, ...
А>Вы заметили о чём нужно было позаботится в первом случае? О том, что при изменении коллекции, енумерацию необходимо перезапускать, иначе — исключение. У меня об этом заботится не нужно. Об этом знает генератор кода.
Откуда он это знает? Как он отличает idict.Remove от Console.WriteLn? А>Вообще структура проще при манипулировании.
Пока что этого не видно. В следуюшем письме я обещаю вставить фрагмент реального кода, и мы посмотрим, насколько
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, <Аноним>, Вы писали:
А>Опять генерики. Ну нету их в .NET 1.1. Не-ту!!! А я не могу сидеть в Visual Studio 2005 — не та мощность у моего ПК. Это кстати, ещё один момент (не самый главный, правда), который останавливает меня от введения в свою среду генериков и других ненужных наворотов.
А ты пробывал Express Edition? В нем уже можно работать на 64 мегах оперативы и проце мегагерц в 500 (операционка Win2k) правда дезайнер притормаживает а так ничего. При 256 мегах и 1000 мегагерц уже вполне комфортно можно работать с небольшими проектами. Team Edition действительно жрет много (500 мегов при загрузке даже без проекта).
Здравствуйте, <Аноним>, Вы писали:
А>>>Вы заметили о чём нужно было позаботится в первом случае? О том, что при изменении коллекции, енумерацию необходимо перезапускать, иначе — исключение. У меня об этом заботится не нужно. Об этом знает генератор кода. S>>Откуда он это знает? Как он отличает idict.Remove от Console.WriteLn? А>Да потому что я заложил в него это!
Ну это ты положим заложить можешь. А если представить следующий случай
List<int> keys = new List<int>(idict.Keys);
foreach (int key in keys)
MegaLib.MegaClass.MegaMethod(idict, key);
Причем MegaLib это сборка реализованая на C# (допустим) и исходниеков к ней нет. И внутри MegaLib.MegaClass.MegaMethod или луче не этого метода а метода который вызывает этот метод и так еще раз 5-6 комуто стукнуло грохнуть элемент key. Как твой генератор должен об этом догадываться? Причем это наверняка не самый сложный случай.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Re[6]: Как вам задумка, а?
От:
Аноним
Дата:
25.09.06 14:37
Оценка:
Здравствуйте, Дьяченко Александр, Вы писали:
ДА>Здравствуйте, <Аноним>, Вы писали:
А>>Опять генерики. Ну нету их в .NET 1.1. Не-ту!!! А я не могу сидеть в Visual Studio 2005 — не та мощность у моего ПК. Это кстати, ещё один момент (не самый главный, правда), который останавливает меня от введения в свою среду генериков и других ненужных наворотов.
ДА>А ты пробывал Express Edition? В нем уже можно работать на 64 мегах оперативы и проце мегагерц в 500 (операционка Win2k) правда дезайнер притормаживает а так ничего. При 256 мегах и 1000 мегагерц уже вполне комфортно можно работать с небольшими проектами. Team Edition действительно жрет много (500 мегов при загрузке даже без проекта).
Express Edition меня не вдохновляет. У меня есть Professional Edition. Проц у меня 800 MHz, памяти 512 и при этом всём тормозит.
Re[6]: Как вам задумка, а?
От:
Аноним
Дата:
25.09.06 14:40
Оценка:
Здравствуйте, Дьяченко Александр, Вы писали:
ДА>Здравствуйте, <Аноним>, Вы писали:
А>>>>Вы заметили о чём нужно было позаботится в первом случае? О том, что при изменении коллекции, енумерацию необходимо перезапускать, иначе — исключение. У меня об этом заботится не нужно. Об этом знает генератор кода. S>>>Откуда он это знает? Как он отличает idict.Remove от Console.WriteLn? А>>Да потому что я заложил в него это!
ДА>Ну это ты положим заложить можешь. А если представить следующий случай
ДА>
ДА>List<int> keys = new List<int>(idict.Keys);
ДА>foreach (int key in keys)
ДА> MegaLib.MegaClass.MegaMethod(idict, key);
ДА>
ДА>Причем MegaLib это сборка реализованая на C# (допустим) и исходниеков к ней нет. И внутри MegaLib.MegaClass.MegaMethod или луче не этого метода а метода который вызывает этот метод и так еще раз 5-6 комуто стукнуло грохнуть элемент key. Как твой генератор должен об этом догадываться? Причем это наверняка не самый сложный случай.
Так ведь структуру проекта создаёт программист! Если я правильно понял пример, то здесь будет несколько вложенных инструкций call. Это программист задаст сам в так называемом моём "построителе выражений" (аналог можно найти в MS Access). А уж построить код по схеме — раз плюнуть для генератора.
Re[2]: Как вам задумка, а?
От:
Аноним
Дата:
25.09.06 14:41
Оценка:
Здравствуйте, Andir, Вы писали:
A>Здравствуйте, <Аноним>, Вы писали:
А>>А теперь критику и мнения в студию!
A>Что-то это всё сильно смахивает на тролля из fido, больно похожа и техника, и пафос ...
Нет, я не из фидо и не был там никогда. Хотя иногда жалею об этом.
Здравствуйте, <Аноним>, Вы писали:
А>>>Опять генерики. Ну нету их в .NET 1.1. Не-ту!!! А я не могу сидеть в Visual Studio 2005 — не та мощность у моего ПК. Это кстати, ещё один момент (не самый главный, правда), который останавливает меня от введения в свою среду генериков и других ненужных наворотов. ДА>>А ты пробывал Express Edition? В нем уже можно работать на 64 мегах оперативы и проце мегагерц в 500 (операционка Win2k) правда дезайнер притормаживает а так ничего. При 256 мегах и 1000 мегагерц уже вполне комфортно можно работать с небольшими проектами. Team Edition действительно жрет много (500 мегов при загрузке даже без проекта). А>Express Edition меня не вдохновляет. У меня есть Professional Edition.
Зря помоему. Если с VS2003 сравнивать так и в Express есть все что надо.
А>Проц у меня 800 MHz, памяти 512 и при этом всём тормозит.
На 800 не работал. Работал на 1.1 Pentium 3, но памяти 192 (На WinXP). Переключение в дизайнер конечно притормаживает, но вобще ничего. Памяти нехватало так как комп из свопа практически не выбирался.
Здравствуйте, <Аноним>, Вы писали:
А>Так ведь структуру проекта создаёт программист! Если я правильно понял пример, то здесь будет несколько вложенных инструкций call. Это программист задаст сам в так называемом моём "построителе выражений" (аналог можно найти в MS Access). А уж построить код по схеме — раз плюнуть для генератора.
Не правильно ты понял — call здесь будет один. MegaMethod статический метод класса MegaClass расположенного в пространстве имен MegaLib. Но это так мелочи. С примером я немного накасячил, вот то что хотел спросить:
Твое представление:
<method 5> EnumerateCollection (System.Collections.IDictionary idict) : bool
| // тело метода
-- <instruction 1> foreach {int key, idict.Keys}
| // тело цикла
-- <instruction 1> MegaLib.MegaClass.MegaMethod{idict, key}
Варианты реализации:
Вариант 1 (idict не модифицируется внутри метода)
foreach (int key in idict.Keys)
{
MegaLib.MegaClass.MegaMethod(idict, key);
}
Вариант 2 (idict модифицируется внутри метода)
List<int> keys = new List<int>(idict.Keys);
foreach (int key in keys)
MegaLib.MegaClass.MegaMethod(idict, key);
S>>>>Откуда он это знает? Как он отличает idict.Remove от Console.WriteLn? А>>>Да потому что я заложил в него это!
Главный вопрос продолжение этого обмена репликами.
На основе чего твой генератор будет выбирать вариант преобразования твоего представления в код? (напоминаю MegaLib отдельная сборка исходников к ней нет).
Здравствуйте, <Аноним>, Вы писали: А>Опять генерики. Ну нету их в .NET 1.1. Не-ту!!!
Во-первых, не суть важно. Можно переписать код и без дженериков. Просто так — короче, а мне не хотелось засорять пример лишним кодом. А>А я не могу сидеть в Visual Studio 2005 — не та мощность у моего ПК.
Ну что я могу сказать? Ты берешься сделать инструмент лучше всех на свете, и при этом сознательно игнорируешь передовые достижения IDE-шной мысли. А>Это кстати, ещё один момент (не самый главный, правда), который останавливает меня от введения в свою среду генериков и других ненужных наворотов. S>>Начинаем докапываться: S>>1. Как выглядит это дерево? Скриншот плиз. Пока что я вижу по-прежнему текст, и никакого ухода от строчек кода не произошло. А>GUI ещё не рабочее.
Paint работает? Вперед! Еще раз тебе повторяю: если ты не можешь нарисовать GUI в Paint, то программу для его рисования ты тем более никогда не напишешь! S>>2. А что, выбирать сами операции уже не нужно? Откуда среда знает, что нужно именно foreach, if, и call? А>Нет, почему же, ещё нужно. Но достаточно выбрать скажем элемент foreach из списка доступных инструкций
Ок. Огласите, пжалста, весь список.
Этот список — он где? В меню? Откуда мы достаем это меню? По правой кнопке на узле твоего дерева? Или Insert->Statement->...? А>и натравить его на на что-то, что поддерживает IEnumerable
О! Что значит "натравить"? Где мы возьмем это что-то, что поддерживает IEnumerable? Напомню, что OOUI требует наличия объекта действия прямо на экране. Ты можешь оценить, сколько объектов, реализующих IEnumerable, может быть в области видимости вставляемого стейтмента? А>- вот инструкция готова (придётся указать только тип элементов, в нашем случае — int). S>>3. Как именно происходит выбор этих параметров? Особенно первого параметра для foreach — там как бы бесконечное пространство вариантов. А>Это программист сам указывает из списка. Только кто сказал, что там бесконечное множество вариантов? Это множество ограниченно типами загруженных сборок + примитивами, и всё. C точки зрения UI 10000 — это то же самое, что и бесконечность. Ты не пробовал посчитать количество публичных типов в стандартных сборках FCL, которые как правило включены в проект? А>Кстати, список доступных операций грузится при загрузке среды за ~10 секунд (иногда даже меньше). А>В принципе, будет так как вы и сказали. Только не правый клик, а выбор в боковой панели из красивого такого списка (точнее это тоже будет дерево, группированное по категориям инструкций, например: элементарные инструкции, окна, файловая система, сокеты, консоль и т.д.).
Отлично. Сколько кликов нужно сделать в этой панели, чтобы найти доступную операцию? А>Далее появляется окно свойств выбранной инструкции, где можно указать параметры для конкретной инструкции (для if — условие, для for — первое значение, условие выхода, значение инкремента и т.п.).
S>>Откуда он это знает? Как он отличает idict.Remove от Console.WriteLn? А>Да потому что я заложил в него это! Отлично. И сколко еще таких хаков ты предполагаешь заложить в свою среду? Как предполагается расширять эти знания?
А>>>Вообще структура проще при манипулировании. S>>Пока что этого не видно. В следуюшем письме я обещаю вставить фрагмент реального кода, и мы посмотрим, насколько А>Вы не поняли! Я говорю при манипулировании!!!
Я-то как раз всё понял. А>Т.е. при изменении параметров инструкций, имён (клавишей F2), и т.д. и т.п. Понимаете, о чём я?
Понимаю. Это называется рефакторинг, и прекрасно работает в существующих средах. Например, в VS 2005, IntelliJ IDEA, и даже в VS 2003 + Resharper. А>Это же всё автонастраиваемые объекты! Т.е. я могу взять из приведённого примера скопировать foreach, затем вставить его в другой метод, у которого аргумент — тоже реализует IDictionary и всё, этот же код будет работать в другом методе без исправлений.
Во-первых, в реальной программе фрагментов кода, которые надо скопировать без изменений, не бывает. А если они есть, то это повод почистить конюшни, образовавшиеся в результате полета творческой мысли. А ты что, правда каждый раз пишешь этот чудовищный код удаления из словаря? Подсказка: правильные пацаны пишут статик метод ClearDictionary(...) и больше никогда об этом не думают.
Во-вторых, совсем без переделок не обойдется. Ведь в целевом методе скорее всего другие агрументы! И тебе как минимум придется настроить foreach: выбрать аргумент для перебора.
В итоге объем затрат сравним с обычным copy-paste, в котором тоже достаточно подправить аргумент in. Причем с учетом code completion это может потребовать меньше нажатий кнопок, чем твой выбор из списков. А>Это как пример.
Ну, пока что пример неудачный.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Как вам задумка, а?
От:
Аноним
Дата:
26.09.06 06:43
Оценка:
Здравствуйте, Дьяченко Александр, Вы писали:
ДА>Твое представление:
ДА><method 5> EnumerateCollection (System.Collections.IDictionary idict) : bool
ДА>| // тело метода
ДА>-- <instruction 1> foreach {int key, idict.Keys}
ДА> | // тело цикла
ДА> -- <instruction 1> MegaLib.MegaClass.MegaMethod{idict, key}
ДА>
ДА>Варианты реализации:
ДА>Вариант 1 (idict не модифицируется внутри метода)
ДА>List<int> keys = new List<int>(idict.Keys);
ДА>foreach (int key in keys)
ДА> MegaLib.MegaClass.MegaMethod(idict, key);
ДА>
ДА>На основе чего твой генератор будет выбирать вариант преобразования твоего представления в код? (напоминаю MegaLib отдельная сборка исходников к ней нет).
Если вы имеете в виду, откуда он знает, изменится словарик в методе или нет — так он этого и не знает. Это ж не ИИ. Просто в окне соответствующей инструкции foreach будут галочки типа "Перезапускать перечисление после изменения коллекции" (будет автоматически установлена, если в теле цикла будет найдена инструкция, явно изменяющая коллекцию, которую перечисляем) и "Выходить из цикла после изменения коллекции". Т.е. вызов idict.Remove (...) полюбому будет считатся изменением коллекции. А вызов MegaMethod — нет. Программист сам должен это знать.
Блин, да вы наверно подумали, что я тут типа ИИ пишу! Нет, не ИИ. Пока, по крайне мере...
Re[6]: Как вам задумка, а?
От:
Аноним
Дата:
26.09.06 06:56
Оценка:
Здравствуйте, Sinclair, Вы писали:
S>Ну что я могу сказать? Ты берешься сделать инструмент лучше всех на свете, и при этом сознательно игнорируешь передовые достижения IDE-шной мысли.
Ничего не знаю. И на VS2003 можно написать VS2010.
S>Paint работает? Вперед! Еще раз тебе повторяю: если ты не можешь нарисовать GUI в Paint, то программу для его рисования ты тем более никогда не напишешь!
Не смешите меня.
S>>>2. А что, выбирать сами операции уже не нужно? Откуда среда знает, что нужно именно foreach, if, и call? А>>Нет, почему же, ещё нужно. Но достаточно выбрать скажем элемент foreach из списка доступных инструкций S>Ок. Огласите, пжалста, весь список.
Я устану его оглашать здесь, ибо он займёт несколько страниц.
S>Этот список — он где? В меню? Откуда мы достаем это меню? По правой кнопке на узле твоего дерева? Или Insert->Statement->...?
Нет, этот список в виде красивого дерева в боковой панели главного окна.
А>>и натравить его на на что-то, что поддерживает IEnumerable S>О! Что значит "натравить"? Где мы возьмем это что-то, что поддерживает IEnumerable? Напомню, что OOUI требует наличия объекта действия прямо на экране. Ты можешь оценить, сколько объектов, реализующих IEnumerable, может быть в области видимости вставляемого стейтмента?
А зачем в пределах видимости???? Вы что, считаете меня совсем за идиота, да? Что такое drag&drop, знаем? Ну так вот. Есть допустим локальная переменная. Мы перетаскивает инструкцию foreach из той самой панели на узел дерева в коде, придствавляющий эту переменную. При этом если эта переменная не поддерживает IEnumerable, то курсор мыши будет значком запрета.
А>>Это программист сам указывает из списка. Только кто сказал, что там бесконечное множество вариантов? Это множество ограниченно типами загруженных сборок + примитивами, и всё. S> C точки зрения UI 10000 — это то же самое, что и бесконечность. Ты не пробовал посчитать количество публичных типов в стандартных сборках FCL, которые как правило включены в проект?
Максимум — 3000 типов. Реально только 1500 типов. .NET 1.1.
S> Отлично. И сколко еще таких хаков ты предполагаешь заложить в свою среду? Как предполагается расширять эти знания?
Много. А расширять... ну так база данных есть для этого. И редактор этой базы данных.
S>Во-вторых, совсем без переделок не обойдется. Ведь в целевом методе скорее всего другие агрументы! И тебе как минимум придется настроить S>foreach: выбрать аргумент для перебора.
Нет, не придётся, если аргумент-коллекция только один.
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, Sinclair, Вы писали:
S>>Ну что я могу сказать? Ты берешься сделать инструмент лучше всех на свете, и при этом сознательно игнорируешь передовые достижения IDE-шной мысли. А>Ничего не знаю.
Мой дорогой анонимный друг, твоя основная проблема именно в этом. Ты действительно ничего не знаешь. И тебе крайне полезно было бы узнать побольше. Например о том, как устроена VS 2005 и что она предлагает. Твой мега-тул будет конкурировать с ней и со следующим поколением IDE, которое выйдет к моменту окончания твоей разработки. Поставь хотя бы решарпер, посмотри что умеют другие.
S>>Paint работает? Вперед! Еще раз тебе повторяю: если ты не можешь нарисовать GUI в Paint, то программу для его рисования ты тем более никогда не напишешь! А>Не смешите меня.
Это ты меня смешишь. Ты вообще имеешь представление о процессе разработки? Ты собираешься построить инструмент, который основан на UI. В нем кроме UI фактически ничего нет. И при этом у тебя до сих пор нет спецификации на этот UI. Это все равно как пытаться собрать атомный реактор без чертежей — прямо так, мастерком и отверткой. S>>Ок. Огласите, пжалста, весь список. А>Я устану его оглашать здесь, ибо он займёт несколько страниц.
Очень хорошо. А почему ты думаешь, что пользователь не устанет делать выбор из списка размером в несколько страниц? Намекаю, что для вставки инструкции foreach в Студии мне достаточно набрать "fore Ctrl+Space". Т.е. 5 нажатий на кнопки, общим временем около 0.5 секунды. S>>Этот список — он где? В меню? Откуда мы достаем это меню? По правой кнопке на узле твоего дерева? Или Insert->Statement->...? А>Нет, этот список в виде красивого дерева в боковой панели главного окна.
Какова характерная глубина этого дерева? Сколько элементов на каждом уровне? А>>>и натравить его на на что-то, что поддерживает IEnumerable S>>О! Что значит "натравить"? Где мы возьмем это что-то, что поддерживает IEnumerable? Напомню, что OOUI требует наличия объекта действия прямо на экране. Ты можешь оценить, сколько объектов, реализующих IEnumerable, может быть в области видимости вставляемого стейтмента?
А>А зачем в пределах видимости???? Вы что, считаете меня совсем за идиота, да?
Ну не то чтобы за идиота. За человека, который плохо представляет себе основы. А>Что такое drag&drop, знаем? Ну так вот. Есть допустим локальная переменная. Мы перетаскивает инструкцию foreach из той самой панели на узел дерева в коде, придствавляющий эту переменную.
Очень хорошо. Уточняем вопросы:
1. А что, если я хочу поитерироваться по нелокальным переменным? Как мне сгенерировать такой вот код:
foreach(Assembly assembly in AppDomain.CurrentDomain.GetAssemblies())
Console.WriteLn(assembly.Name)
? Куда я должен перетащить значок foreach из левой панели?
2. Как определяется, куда будет добавлена вставляемая инструкция? До сих пор я полагал, что я перетащу ее именно на то место в дереве, которое соответствует точке вставки. Теперь оказывается, что перетаскивать надо вовсе даже на аргумент foreach. Ok, а инструкцию while куда надо будет перетаскивать? А>При этом если эта переменная не поддерживает IEnumerable, то курсор мыши будет значком запрета.
Ух ты! А как ты собрался это определять? Далеко не во всех случаях можно статически определить наличие поддержки IEnumerable. Грубо говоря, отсутствие поддержки гарантируется только для sealed классов и value типов. Для не-sealed reference типов всегда есть риск получить реализацию IEnumerable в фактическом типе (кроме случаев, когда точный тип удается вывести в локальном контексте). Ты это учел в своих предположениях? А>Максимум — 3000 типов. Реально только 1500 типов. .NET 1.1.
1500 — это ОЧЕНЬ много для визуального выбора. У меня помещается примерно 60 строк на экране студии. 1500 — это 25 страниц. Как ты собираешься оптимизировать выбор из списка такой длины? Сделаешь инкрементальный поиск по названию класса? Ой, это уже есть в студии 2003. Почему ты думаешь, что твой способ будет лучше? А>Много. А расширять... ну так база данных есть для этого. И редактор этой базы данных. А>Нет, не придётся, если аргумент-коллекция только один.
Извини, а ты вообще реальный код когда-нибудь видел? Поясняю: шансы, что у меня два однопараметрических метода с IEnumerable аргументом, в которых понадобится одинаковый код, равны нулю. Нет востребованности в такой функциональности.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Как вам задумка, а?
От:
Аноним
Дата:
27.09.06 10:15
Оценка:
:D :D :D
Карочи, опустили товарисча ниже плинтуса.
Нда... так мы вечный двигатель никогда не изобретем...
How can men die better than facing fearful odds,
For the ashes of their fathers and the temples of their gods?
Здравствуйте, BlackTigerAP, Вы писали:
>>>Аноним просто мелко плавал еще...
BTA>Да молодой он еще просто. Энергии и идей много, опыта мало. Решил объять необъятное. Пусть делает, что хочет. Лучший источник опыта — шишка на собственном лбу.
Господа, зачем же такой пессимизм? Почитал всю тему и обнаружил всего трех оптимистов, включая себя, автора темы и Lever. Кто-то в данной теме нас романтиками назвал -- ну, а почему бы и нет? Немножко тривиальщины: есть фундаментальные исследования, а есть прикладные. Прикладными исследованиями занимаются чистые практики. Фундаментальными -- изначально занимаются энтузиасты. Лишь затем фундаментальные исследования могут перерасти в прикладные. Идеи автора пока относятся к разряду фундаментальных (глобальных и не вполне обычных) -- потому и споров так много. Однако это не значит, что они невозможны. Лично я не вижу в них ничего принципиально нереализумого. Это отнюдь не вечный двигатель. А насколько практичной будет система -- буудет ясно, когда она будет готова
Я бы посоветовал автору просто доделать пилотный вариант системы, выложить его с подробным описанием в Интернет, и уже потом предложить обсудить его на форуме. Может я к тому времени раскачаюсь выложить и свою систему -- у критиков будет больше объектов для обсуждения
И еще пару слов на высокие философские темы
Было мнение, что блочная система принципиально ограничена, потому что наш мир фрактален. Так вот -- фракталы -- рекурсивные (вложенные) структуры. Ничто не мешает описать их с помощью блоков. Во-первых, блок может содержать вложенные блоки. Во-вторых, с точки зрения типизации блоков -- блок является по сути объектом, то есть экземпляром класса. Если класс есть элемент иерархии (дерева классов), то и здесь нет никаких существенных противоречий с фракталами. Еще один момент -- фрактальные структуры имеют бесконечную вложенность. Это можно описать блоком, ссылающимся на самого себя. Так что никаких философских причин, мешающих представить мир блоками я не вижу. Если конечно, не опуститься на уровень квантовой механики и прочих страшных (принципиально вероятностных) вещей
Re: Как вам задумка, а?
От:
Аноним
Дата:
02.10.06 16:43
Оценка:
Все это очень похоже на реализацию триггеров в стандартном редакторе для WarcraftIII. Когда сначала увидел — решил, что все очень просто и хорошо.
Но там есть такая проблема: допустим, у нас есть комманда — передвинуть юнита (сложное выражение) в точку А. Надо эту комманду поменять на такую — приказать двигаться юниту (сложное выражение) в точку А. И оказывается, что это сложное выражение, настраеваемое в 10 окнах, никаким образом нельзя скопировать, и его надо вводить заного.
Конечно, подобные проблемы можно решить, но тогда будут возникать другие. А все потому, что есть два подхода к работе за компьютеров, отличающиеся в корне — работа клавиатурой, и работа мышью. Первый из них подразумевает работу с текстом, а второй — с графикой. И какие бы горячие клавиши не придумывались, первый из них при написании программ всегда будет продуктивнее.
Здравствуйте, Аноним, Вы писали:
А>дайте хоть бы одну ссылку А>и вообще, если такое уже реализованно, то почему же люди до сих пор программируют в Visual Studio, а не собирают код из кусочков?!!
Virtools. То о чем ты рассказываешь. Это уже реализовано. Этот продукт приводит к тому что профессия программист становится не нужной. Есть фирмы создающие 3D игры не имеющие в штате ни одного программиста. Одни дизайнеры.
А>Ладно, короче, тут видимо чушь уже понеслась уже в этой теме... А>Ждите бета-версию. А>Думаю, тогда вы по-другому заговорите.
Звучит как угроза.
«Время жизни складывается не из количества прожитых вздохов, а из секунд в которые у тебя захватывает дыхание.»
(с) фильм «Метод Хитча»
Re[4]: Как вам задумка, а?
От:
Аноним
Дата:
05.10.06 09:40
Оценка:
Здравствуйте, DrMom, Вы писали:
DM>Здравствуйте, Аноним, Вы писали:
А>>дайте хоть бы одну ссылку А>>и вообще, если такое уже реализованно, то почему же люди до сих пор программируют в Visual Studio, а не собирают код из кусочков?!!
DM>Virtools. То о чем ты рассказываешь. Это уже реализовано. Этот продукт приводит к тому что профессия программист становится не нужной. Есть фирмы создающие 3D игры не имеющие в штате ни одного программиста. Одни дизайнеры.
Я думаю, что вышеназванная штуковина является узкоспециализированной, т.е. для игр.
Я же просил дать хотя бы одну ссылку на продукт аналогичный VS, но при этом чтобы в нём была абстракция от кода.
Re[2]: Как вам задумка, а?
От:
Аноним
Дата:
05.10.06 09:51
Оценка:
Здравствуйте, Paulmay, Вы писали:
P>Все это очень похоже на реализацию триггеров в стандартном редакторе для WarcraftIII. Когда сначала увидел — решил, что все очень просто и хорошо.
Не довелось мне к сожалению поиграть в WC3...
P>Но там есть такая проблема: допустим, у нас есть комманда — передвинуть юнита (сложное выражение) в точку А. Надо эту комманду поменять на такую — приказать двигаться юниту (сложное выражение) в точку А. И оказывается, что это сложное выражение, настраеваемое в 10 окнах, никаким образом нельзя скопировать, и его надо вводить заного.
Да, эту проблему можно решить легко. И все остальные подобные проблемы. Т.к. это вовсе и не проблемы.
P>И какие бы горячие клавиши не придумывались, первый из них при написании программ всегда будет продуктивнее.
Зависит от человека.
А вообще, я считаю, что любые существующие технологии (например, .Net) можно расширять только одним способом: писать дополнительные классы, методы и т.п., облегчающие работу в той или иной области. Это не плохо, конечно. Но эти дополнительные методы и т.д. всё равно нужно будет писать. На каком-либо языке. Моя же задача (в перспективе) написать нечто интеллектуальное, генерирующее соответствующий код по заданным программистом параметрам. И расширяемость здесь — плугины, которые будут понимать определённые "просьбы" программиста и генерировать соответствующий код. Повторяю: это в перспективе, и ещё не скоро. Но определённые мысли уже есть. Я думаю, надо двигаться именно в этом направлении. Но одно ясно: писать такую задачу, основываясь на объектно-ориентированном ядре (какое у меня сейчас и есть) проще в 100ни раз, чем писать парсер, писать потом переводить полученное дерево в код, потом ещё там что...
Re[2]: Как вам задумка, а?
От:
Аноним
Дата:
05.10.06 09:58
Оценка:
Здравствуйте, _JoKe_, Вы писали:
_JK>[censored]
_JK>теперь по существу.... очень похоже на очень молодого программиста, который просто не умеет на клавиатуре работать, и его очень утруждает одним пальцем набирать по слову в минуту.
Вообще-то скорость у меня набора кода весьма высокая. Возможно, есть и выше, не спорю...
_JK>если думаешь что идея супер гениальная предлагаю простой тест — сделай так как сделал г-н Вирт, когда писал первый паскаль — если не в курсе поясняю — он написал его — ВНИМАНИЕ на ПАСКАЛЕ, и скомпилировал на листике ручкой и мозгами..
Вирт упился пива наверно, когда изобретал супер-мега-гига паскаль свой... Убожество.
_JK>так вот возникает вопрос если твоя идея такая мега гениальная зачем ты пользуешься допотопными, неудобными средствами для её реализации?? реализуй её в своей СУПЕР среде! и получи все вышеназванные тобой преимущества!!!, а мы посмотрим через сколько времени тебе понадобится чтобы реализовать хотя бы то что ты там, как сам утверждаешь уже набросал на допотопном объектно-омперативном языке...
Ты сам понял, что сказал?
Как я реализую свою идею на том, чего ещё нет?
_JK>а потом сравни сколько усилий тебе потребовалось при первом и втором способе... если будет не стыдно выложешь результаты.... (хотя очень сомнительно что вообще используя твой мегапроект ты не застопоришься через час-два уперевшись в неразрешимую проблему, или закопавшись в обилии стрелочек,квадратиков, и treeview).
Когда я закончу проект, мне будет не того, чтобы переписывать его с нуля в своей среде.
Re[5]: Как вам задумка, а?
От:
Аноним
Дата:
05.10.06 10:00
Оценка:
Здравствуйте, nuclearfox, Вы писали:
N>Просмотрел пост... ну что ту скажешь. Приятно, с одной стороны, наблюдать романтиков. Хочется даже пойти в парк стихи почитать. Блока, например, или Вильяма Блейка.
Кто-то программы пишет, а кто-то стихи читает Каждому — своё
Re[8]: Как вам задумка, а?
От:
Аноним
Дата:
05.10.06 12:04
Оценка:
Посмотрите этот топик. Потом на его дату, потом попытайтесь посмотрите когда был последний пост автора. А задумки были попроще Ваших, всего только ERP.
Хочется верить, что автору просто стыдно, надеюсь ничего плохого, так как автор пошел дальше, он не просто планировал, но и вкладывался материально...
Вы, конечно, можете попытаться реализовать Вашу мегасистему (кто знает может Вы юный Билли), по-крайней мере мозгов, от этого точно не убавиться. Только без обид. Я сам проходил подобную стадию "все автоматизирую", только к своему стыду планы были по-скромнее. Мало того все компьютерное сообщество проходило подобную стадию. Сейчас от мега ерп систем все идет все-таки к локализации (в смысле затачиванию под определенные системы).
Здравствуйте, Димон, Вы писали:
Д>Вы, конечно, можете попытаться реализовать Вашу мегасистему (кто знает может Вы юный Билли)
Может быть и Билл, но у Билла, кроме «гаража» был еще и товарищ. Товарищ в таком деле просто необходим, и не для того, чтобы написать в два раза больше, а скорее, чтобы не написать, что не попадя.
Опять же из опыта. Писал проекты, где был единоличным лидером, и такие, где был одним из двух «отцов основателей», по меткому выражению молодежи.
Так вот, вторые по стилю разработки и по качеству существенно отличались.
Re[5]: Как вам задумка, а?
От:
Аноним
Дата:
06.10.06 08:08
Оценка:
Здравствуйте, Lever, Вы писали:
L>А делать надо с точностью до наоборот. L>Строить сразу модель на дереве объектов, использую графические редакторы, которые могут использовать диаграммы UML для конкретных объектов.
Кстати, именно так и происходит в моей среде.
Re[5]: Как вам задумка, а?
От:
Аноним
Дата:
06.10.06 08:55
Оценка:
Аноним, как в вашей среде создать консольное приложение выводящие стандартную фразу "Hello world!" ?
Вот шаги для Visual Studio 2005, язык C#
1. Запустить Visual Studio.
2. Выбрать File->New->Project.
3. В Project types выбрать Visual C#.
4. В Templates выбрать Console Application.
5. Жмем "ОК".
6. Студия сама генерирует начальный код, мы пишем только
Console.WriteLine("Hello world");
Console.ReadKey();
7. Запускаем приложение. всё работает так как мы и хотели.
Теперь давайте подсчитаем сколько действий мне потребовалось сделать по каждому шагу.
1. Запуск. тут каждый запускает по разному, кто с ярлыка на рабочем столе, кто с quicklaunch, кто из меню пуск и.т.д. поэтому этот шаг не учитываем.
2. 2 клика мышью.
3. 1 клик
4. 1 клик
5. 1 клик
6. перемещаем курсор за "{" после функции main, давим Enter, пишем
Cons нажимаем enter (cons дополняется до Console) ставим "." пишем
"Wr" давим стрелку вниз и жмем на enter получаем (Console.WriteLine) пишем следующий текст "("hello world");" жмем Enter. Пишем "Co" жмем на enter получаем "Console" ставим "." пишем
"ReadK" жмем на Enter получаем "ReadKey" пишем "();"
После подсчета получаем: 1 клик мышью, 41 нажатие клавиш
7. Давим F5, 1 нажатие клавиши
ИТОГО: 6 кликов мышью и 42 нажатия на клавишу для создания приложения.
Время на создания этого приложения зависит только от того сколько у кого запускается студия и загружается новый проект, так как эти 2 строчки кода писшутся секунды.
Если вам не трудно, распишите, пожалуйста, в таком же стиле.
Хочу заметить, что отмазка моя среда еще в разработке не подходит, так как такие элементарные вещи, должны быть известны до того как написана первая строчка кода. разрешается погрешность в несколько кликов.
Mastering .NET doesn`t make you a geek
It makes you a geek worthy of a raise
Здравствуйте, LiteX, Вы писали:
LX>Аноним, как в вашей среде создать консольное приложение выводящие стандартную фразу "Hello world!" ?
См. выше.
LX>Если вам не трудно, распишите, пожалуйста, в таком же стиле.
Лень. Принцип я описывал уже (см. выше).
LX>такие элементарные вещи, должны быть известны до того как написана первая строчка кода
Не факт.
------------------------------
Ну, отмазываться я и не собираюсь.
Я только хочу сказать, что вы пытаетесь протестить мою среду на скорость в сравнении, это правильно, но вы приводите не те примеры. Ибо на коротких участках кода (2-3 строчки) выигрыша именно в скорости не будет. Здесь выгода будет только в удобстве и наглядности. Выгода во всём будет очевидна только при разработке больших проектов, когда у человека, сидящего за VS, будет уже отваливаться рука от набора кода, а у человека за моей средой будет хорошее настроение от того, что его код так красиво нарисован в виде дерева (или диаграммы, может быть...).
Re[6]: Как вам задумка, а?
От:
Аноним
Дата:
06.10.06 10:46
Оценка:
LX>такие элементарные вещи, должны быть известны до того как написана первая строчка кода >Не факт
Хорошо, согсласен. Каждый клик продумать не возможно, главное сдесь было написание 2-х строк кода.
вопрос. Через сколько времени можно будет скачать вашу среду? чтобы посмотреть на нее в действии. пусть на первое время будет без документации, но с примерами ее работы.
Mastering .NET doesn`t make you a geek
It makes you a geek worthy of a raise
Здравствуйте, LiteX, Вы писали:
LX>вопрос. Через сколько времени можно будет скачать вашу среду? чтобы посмотреть на нее в действии. пусть на первое время будет без документации, но с примерами ее работы.
Хотел бы я сам это знать... Нас ведь пока всего двое над ней трудится... Конкретно в данный момент я ей не занимаюсь, т.к. ядро почти готово, и я жду пока гуёвщик сделает нужные компоненты, из которых можно собрать главное IDE среды.
В общем, не знаю пока.
Re[7]: Как вам задумка, а?
От:
Аноним
Дата:
07.10.06 10:54
Оценка:
ждем-с
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
Поверьте, мне самому хочется всё закончить как можно быстрее. Но нас всего двое...
Если бы хоть ещё пару человек присоединилось бы, это ведь блин не такой уж и огромный проект...
Re[8]: Как вам задумка, а?
От:
Аноним
Дата:
07.10.06 22:00
Оценка:
Ув. аноним мне интересен braibfucking, пишите на a l e x e y s s @ g m a i l . c o m и посмотрим может помогу, но только скажу сразу мне нужен исключительно brainfucking, об остальком по почте
Mastering .NET doesn`t make you a geek
It makes you a geek worthy of a raise
Здравствуйте, LiteX, Вы писали:
LX>ИМХО если проект изменит мир, то он огромен и крут ...
Собственно, именно с целью изменить мир он и создаётся. А иначе на хрена вообще нужны проекты...
Re[9]: Как вам задумка, а?
От:
Аноним
Дата:
08.10.06 12:23
Оценка:
>>А иначе на хрена вообще нужны проекты...
Дарагой Вы наш... Тебе сколько годочков? И семья уже есть, пара детишек? Родители, которым помогать надо, тоже есть? Квартирка собственная есть? Почему-то мне кажется, что далеко не всё из этого списка присутствует.
Так вот. 99% проектов делаются ради... ДЕНЕГ. Ибо профессия программист, как и любая другая, подразумевает зарабатывание ДЕНЕГ. Но ты еще слишком молод (или глуп? или не нуждаешься вних вообще?), чтобы понять это. Идиалист ты наш... :D
How can men die better than facing fearful odds,
For the ashes of their fathers and the temples of their gods?
Здравствуйте, BlackTigerAP, Вы писали:
>>>А иначе на хрена вообще нужны проекты...
BTA>Дарагой Вы наш... Тебе сколько годочков? И семья уже есть, пара детишек? Родители, которым помогать надо, тоже есть? Квартирка собственная есть? Почему-то мне кажется, что далеко не всё из этого списка присутствует.
BTA>Так вот. 99% проектов делаются ради... ДЕНЕГ. Ибо профессия программист, как и любая другая, подразумевает зарабатывание ДЕНЕГ. Но ты еще слишком молод (или глуп? или не нуждаешься вних вообще?), чтобы понять это. Идиалист ты наш... :D
В вас очень много желания поучить других. В вас много агрессии.
Вы видимо очень старый (это не преимущество передо мной). Вы погрязли в зарабатывании денег (хотя я тоже не без этого, но вы — погрязли в зарабатывании денег). Не надо говорить другим, что они глупы, ибо вы не знаете других и у вас недостаточно для этого оснований.
Спорить с вами не буду.
Просто попрошу вас не писать больше здесь ахинею. Ветка была создана с целью обсуждения моей идеи и высказывания околотемных идей и мыслей.
Re[9]: Как вам задумка, а?
От:
Аноним
Дата:
09.10.06 06:26
Оценка:
>Дарагой Вы наш... Тебе сколько годочков? И семья уже есть, пара детишек? Родители, которым помогать надо, тоже есть? Квартирка собственная есть? Почему-то мне кажется, что далеко не всё из этого списка присутствует.
Так вот. 99% проектов делаются ради... ДЕНЕГ. Ибо профессия программист, как и любая другая, подразумевает зарабатывание ДЕНЕГ. Но ты еще слишком молод (или глуп? или не нуждаешься вних вообще?), чтобы понять это. Идиалист ты наш... :D <
Честно сказать, согласен с BlackTigerAP. Все эти цветочки, лозунги становятся не так актуальны, когда отвечаешь не тока за себя, но и за жену с детьми.
Но вопрос не в этом. В чем же Ваша цель (без всяких обид пж и задних мыслей). А именно цель Вашего проекта. Облегчить жизнь всем программистам или деньги заработать? Может какая-то другая скрытая цель. Надеюсь, не проект ради проекта.
Вы спросили нашего мнения про Вашу "задумку". Вам ответили, что проект изначально расчитан на провал и он материально убыточен. Вам даже указали причины, но Вы упорно пытаетесь отбрыкаться от скромного опыта данного сообщества.
Возможно, Вы современный Эдисон. И Ваша 1000я лампочка загорится. Но у Эдисона был план. А у Вас, к сожалению, его не видно.
ЗЫ Убедительная просьба, не воспринимать мою критику как личные выпады и тп. Меня очень интересует Ваша цель и причины выбора подобной. Я встречал различные идеи, но такой ... еще нет.
ДА>>Ты бы скиншотов или концептуальных рисунков каких-нибудь выложил. Может проще было бы обеснять.
А>Ну пока там и смотреть нечего. Я сейчас ядром среды занимаюсь пока... А GUI на таком уровне, что...
А вот и зря. Идея эта не нова и даже тут неоднократно обсуждалась. Ведь электронщики давно делают предложенное, правда?
Сделать т.н. "ядро" для рендеринга модели в готовый код не так уж и сложно. Ты бы лучше покумекал насчет того, как это будет выглядеть. Для примера показал бы процесс графического (юзером в GUI) составления хотя бы несложных алгоритмов, или ORM данных из базы на некую иерархию объектов.
А>Несколько позже я обязательно выложу и презентаху, и картинки, да и саму прогу. Первая версия будет бесплатной, чтобы как можно больше народу смогли ознакомиться с ней.
Начни именно с картинок и только с них. Если вдруг (ну а вдруг?) тебе удасться найти приемлимый способ представления и приемлимые сценарии GUI-взаимодействия с моделями, то желающих закодить это найдется много, не волнуйся.
(Очень рекомендую много посидеть в различных сложных CAD-системах для электронщиков, может это подскажет тебе что-нить )
Здравствуйте, AndrewVK, Вы писали:
А>>Если есть вопросы — задавайте.
AVK>Чем это отличается от компонентов?
ИМХО, в такой системе библиотеки должны быть не в виде бинарных компонент, а в виде параметризируемых паттернов и шаблонов будущих целевых компонент как результата работы системы.
AVK>Очень спорно. Впрочем, попробуй взять кусок более менее сложного кода, и представь его графически, и мы посмотрим.
+1
AVK>Опять же, если уж очень хочется графически, то welcome to class diagrams.
AVK>Видтшь ли, твоя идея с графически-бинарным представлением ох как не нова. Самая известная реинкарнация — UML. Только вот на практике оказалось, что текстовое все же удобнее.
Среди диаграмм UML нет чего-то типа блок-схемы алгоритма, к сожалению. Далее, state-chart слишком схематичен, по нему можно сделать достаточную для генерации кода модель только в том случае, если предполагается автоматная реализация (однажды именно так и сделали на одной из фирм, где я работал: написали рендерер, который генерит на С++ исходный код автомата по UML-модели, и отладка свелась к отладке модели... разумеется, этот рендерер был насквозь специфичен для конкретного участка нашей системы, но прецендент налицо )
А>>вы понимаете, что компоненты — это статические элементы,
AVK>Конечно же это не так. Весь дизайн-тайм компонентов это чистая динамика.
И зачем ты издеваешься над ним?
AVK>Это именно он и есть. При нормальном написании кода нет нужды копировать куда то куски кода. Я, к примеру, даже code snippets не пользуюсь, что уж говорить о более крупных блоках? В современных языках средств реюза кода более чем достаточно.
Не соглашусь. Несоответствия контрактов иногда начинается прямо из такой "мелочи", как выбор разрядности и точности представления тех или иных данных. От этого выбора никуда не деться, он необходим. Более того, подобное уточнение хотелось бы делать уже ближе к концу разработки, однако сплошь и рядом такое уточнение делается ближе к концу этапа проектирования (или того хуже — проектирование начинается с этой фигни).
А генерики в дотнете, к сожалению, не могут обслужить даже такую мелочь, как подстановка различных численных типов в некие алгоритмы, требущие вычислений. И вот мы получаем искусственное дробление одного контракта на тонны дублирующих (тонны из-за комбинаторных сочетаний различных типов). И вот получаем отсутствие реюза на ровном месте. Некоторые динамические языки в этом плане гораздо более реюзабельны (Смолтолк, Схема).
Я автору посоветовал посмотреть на современные навороченные CAD для электронщиков. Заодно можно вспомнить Форт, например. На нем очень многие слова начального уровня пишут на асме, ну а все остальное — уже с помощью этих слов и далее по возрастающей.
S>2. Описать типичные шаги, которые выполняются пользователем в существущем подходе (или нескольких подходах) S>3. Описать типичные шаги, которые надо будет выполнить в вашем решении.
S>Если речь идет о повышении удобства, то необходимо и достаточно доказать или хотя бы обосновать сокращение количества элементарных действий в п.3. по сравнению с п.2.
А это даже и не надо пока. Достаточно хотя бы достижимости п.3. В визуальных системах кайф от другого можно словить и сэкономить время в совсем другом месте. Я тут постоянно говорю, что миллионы программистов все время пишут одно и то же, при чем при любом масштабе рассмотрения вопроса, от глобальных задач, до конкретных участков кода. И отлаживают это постоянно. Не задумывался, почему ПО глючит куда как чаще железа? Доходит до того, что глюки современного "железа" идут от ПО, которое это железо содержит.
Здравствуйте, 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.
так что кто прав а кто нет еще не известно.
... << RSDN@Home 1.1.4 @@subversion >>
Re[12]: Как вам задумка, а?
От:
Аноним
Дата:
12.10.06 13:31
Оценка:
Да сходите вы по той ссылке, что я дал.Там, типа, сделано как то, о чем аноним тут распинался. Посмотрите сами к чему это привело.
How can men die better than facing fearful odds,
For the ashes of their fathers and the temples of their gods?
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
_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, тут же все преимущества визуального программирования гаснут и никакой существенной пользы, ускорения программирования, и всего остального не приносят.
Тогда поясню. В визуальных средах для электронщиков, на том месте где написано Filter<T> пишут марку микросхемы или ее обобщенное название (на блок-схемах). В системах, где упор делается на моделирование, вместо безликих "квадратиков" для внешнего представления компонент могут быть использованы более выразительные образы. Для нашего примера это может быть стиллизованное графическое представление фильтра (в виде привычной воронки, например).
Здравствуйте, _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) код уникален.
если предположить что все варианты кода в мире систематизируется и складывается в гипотетическое хранилище (задача сама по себе слабо решаемая)
то я сомневаюсь что найти среди миллиардов различных отрывков кода нужный тебе, проверить его что это действительно то что тебе надо и оттестировать в реальном проекте будет проще и быстрее, чем написать свой.
V>Почему индустрия до сих пор еще не созрела до такого разделения труда?
Почему не созрела? Компоненты и визуальные редакторы придуманы давным давно. Визуальный редактор форм уже стал стандартом. В 2005 студии штатно есть class designer графический.
А то, что логику нельзя так рисовать, так об этом тебе и говорят. Не везде идеология собирания программы из готовых блоков удобна и уместна.
AVK>А то, что логику нельзя так рисовать, так об этом тебе и говорят. Не везде идеология собирания программы из готовых блоков удобна и уместна.
И я даже знаю, где проходит граница м/у этими "не везде". Всё, что можно описать декларативно, теоретически вполне поддается визуальному дизайну и параметризации. Я считаю, что процент императивного пока что неоправданно высок. Я бы оставил в большинстве случаев только формулы какие-нить.
V>Тогда поясню. В визуальных средах для электронщиков, на том месте где написано Filter<T> пишут марку микросхемы или ее обобщенное название (на блок-схемах). В системах, где упор делается на моделирование, вместо безликих "квадратиков" для внешнего представления компонент могут быть использованы более выразительные образы. Для нашего примера это может быть стиллизованное графическое представление фильтра (в виде привычной воронки, например).
как в анекдоте про такси — "вам шашечки или ехать?"
программистам не надо красивости и т.п. им надо чтобы алгоритмы были правильные и архитектура в целом.
что до дизайнеров и всего остального НУ НЕ НУЖНЫ ОНИ в большинстве случаев, может быть только в начале обучения когда проходит стадия "изучаю VC2003 за 24 урока ",
я например не пользуюсь вообще никакими дизайнерами классвизардами и прочим(кроме редактора ресурсов), как показывает практика если знаешь что писать руками набивать быстрее проще и надежней. и вообще большУю часть работы пишу в редакторе от Far-а.
так и тут — не надо грузить программиста разглядыванием всяких картинок "стилизованных", работа программиста — продумывать механизмы взаимодействия частей системы в целом, подбор правильных алгоритмов, налаживание взаимодействия между частями системы и продумывание ситем ввода-вывода, и паралельно код строчить..., это совсем не сложно и не надо тут ничего упрощать...
как говорит дядя Паретт 80/20
80% времени создается и обдумывается архитектура
20% пишется код....
(а на самом деле может и 95/5)
небольшое ускорение написания кода — бессмысленная трата времени.... надо архитектура быстрее и лучше продумывалась, чтобы её потом еще 5-10 раз пересмотреть не пришлось, а для это не тулзы нужы а мозги и развивать их надо посещением лекций чтением литературы и т.д. тогда можно получить большой прирост производительности.
короче говоря: 1 хороший проффессионал имея под рукой любой текстовый редактор и компилятор, решит задачу быстрее, лучше и эффективнее, чем комманда из 10 так себе программеров до зубов вооруженных вспомогательными IDE, тулзами, дебаггерами, профилерами, редакторами, UML и т.д. и т.п
... << RSDN@Home 1.1.4 @@subversion >>
Re[3]: Исправлен "рисунок"
От:
Аноним
Дата:
16.10.06 12:38
Оценка:
Визуальное проектирование в электроники это только один шаг в создание реально работающей системы. В любой серьезной системе есть микроконтроллер для которого надо писать программу и тут уже нет никакой визуализации, повезет если язык будет С, а не ASM.
Mastering .NET doesn`t make you a geek
It makes you a geek worthy of a raise
_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 проектов, в совокупности составляющих лишь одну из частей нашей системы. Уметь помнить все подробности всех проектов наизусть чтобы мочь писать/отлаживать в ФАРе быстрее, чем грузится студия? Я бы многое отдал за это.
Синклер, ты нудный. В той ссылке я говорил о том, что многие базовые вещи действительно удобно описывать на ЯП. Возьми, например, среду моделирования 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: вижу что обсуждение перешло совсем не в ту сторону поэтому не считаю целесообразным и далее выступать в роли Кассандры и открывать глаза людям которые совсем не хотят ничего знать, поэтому считаю далее продолжать разговор в этой ветке бессмысленным, на том и заканчиваю.
Здравствуйте, _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 балла.
Здравствуйте, Paulmay, Вы писали:
P>Для тех, кто в танке, объясняю: добавление одного оператора в графической среде займет в среднем около 2-5 секунд (надо как минимум найти курсором этот оператор и перетащить его обратно). Это время будет постоянно увеличиваться из-за износа мышки, у которой не больше пяти кнопок. В то же время набор этого оператора на клавиатуре займет не более секунды, кроме того, у клавиатуры больше срок работы, так как у нее больше клавиш. Таким образом, скорость работы в графической среде только понизится.
Никого не интересует программирование в операторах.
Я тут много ссылок давал: Re[4]: Исправлен "рисунок"
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, _JoKe_, Вы писали:
V>>>Мне вообще-то плевать как именно это сделано у вас. Я спросил — вы по быстродейтсвию сравнивать свои алгоритмы в вашей системе с оными в Cache пробовали, прежде чем воротить свое аналогичное?
_JK>>конкретно с кэш не пробовали, скажу честно, уверен что кэш будет медленней, ибо у нас скорость расчета равна скорости чтения данных с носителя. т.е если для рассчета необходимо зачитать 1гб данных, то рассчет закончится с той же скоростью как и закончится копирование этих данных в /dev/null.
V>Все зависит от того, как вы эти данные храните. Преимущество обработки на стороне базы в том, что не надо тянуть эти данные в другой процесс и хост. И не говори, что вы храните гиги данных просто в файлах.
именно так в специально подготовленных плоских файлах.... ты похоже просто не знаком с OLAP системами.
V>Если ты обратил внимание, то я упирал больше на middle-ware, а это немного не то, что ты озвучил. Это — наработанные способы решения типовых мелочей. Магазин из них строится, хотя сам может быть блоком, разумеется. Насчет "залить в базу" — это не для красного словца, надеюсь понимаешь? Большинство классов приложений так или иначе обрабатывают данные, и базы -это пока безальтернативный способ надежного их хранения и более-менее быстрой массовой обработки. (свой пример с Ораклом и вашим императивным алгоритмом не приводи, насколько я понял, у вас там всего несколько отчетов так строятся, для сравнени — в средней ERP разновидностей отчетов более тысячи). И тем не менее, тонны рукописной работы до сих пор в ORM наблюдается. Почти в любом топике здесь, где кто-либо показывает пример удачной кодогенерации по шаблонам, по базам, автор срывает самые бурные апплодисменты зала. Поневоле призадумаешься, как же так выходит-то, что самая востребованная вещь (судя по реакции) как-то сбоку, неинтегрированно, жутко узкоспециализированно и вообще, сто раз подумаешь, а стоит ли связываться.
не говори того чего не знаешь еще раз — ознакомся с тем что такое OLAP...
отчетов у нас тысячи а могут быть и миллионы, мы из не создаем они абсолютно динамические юзер их сам строит.
V>>Все зависит от того, как вы эти данные храните. Преимущество обработки на стороне базы в том, что не надо тянуть эти данные в другой процесс и хост. И не говори, что вы храните гиги данных просто в файлах.
_JK>именно так в специально подготовленных плоских файлах.... ты похоже просто не знаком с OLAP системами.
Да ну? У вас самопальная OLAP-система? Те, с которыми я знаком, хранят данные в базе в "специально подготовленных плоских таблицах".
_JK> не говори того чего не знаешь еще раз — ознакомся с тем что такое OLAP...
После подобных выпадов всегда охота поинтересоваться каков возраст собеседника. А то может получиться так, что на время тратится на самоуверенного студента.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, _JoKe_, Вы писали:
V>>>Все зависит от того, как вы эти данные храните. Преимущество обработки на стороне базы в том, что не надо тянуть эти данные в другой процесс и хост. И не говори, что вы храните гиги данных просто в файлах.
_JK>>именно так в специально подготовленных плоских файлах.... ты похоже просто не знаком с OLAP системами.
V>Да ну? У вас самопальная OLAP-система? Те, с которыми я знаком, хранят данные в базе в "специально подготовленных плоских таблицах".
читай внимательно — всю ветку — те с которыми ты знаком которые хранят в "специально подготовленных плоских таблицах" в оракле — не справляются с нагрузкой.
в нашей системе НЕ ИСПОЛЬЗУЕТСЯ НИКАКИХ СТОРОННИХ ПРОДУКТОВ ВООБЩЕ (не считая ASP.NET для веб клиента)
_JK>> не говори того чего не знаешь еще раз — ознакомся с тем что такое OLAP...
V>После подобных выпадов всегда охота поинтересоваться каков возраст собеседника. А то может получиться так, что на время тратится на самоуверенного студента.
если очень интересно — 26.
Здравствуйте, BlackTigerAP, Вы писали:
BTA>Твой вопрос, вообще, даже не технического плана, а, скорее, филосовского. Наш мир не состоит из блоков, хотя это и может так показаться. Наш мир фрактальный. А мы — порождение нашего мира со всеми вытекающими. Если бы мир был блочным, то всё кругом состояло бы из кубов и квадратов, как самых приспособленных для сборки. Никаких закругленностей и угловатостей, за исключением прямых углов. Ан нет, куда не посмотри — фракталы, самый неблочный тип, самый порядочно-беспорядочный. Вроде бы посмотришь — вот он блок! А присмотришься по-ближе — ё моё... Короче, фракталы рулят этим миром, а не блоки. Любая попытка унификации и блокоизации этого мира обречена на провал изначально.
Ты умудрился однобоко посмотреть на правила построения мира. Рулит по-прежнему декомпозиция, просто эта декомпозиция бывает разного характера. Бывает блочного (структурного), а бывает функционального. Почему законы построения любых организмов записаны всего в одной клетке ДНК?
V>>Да ну? У вас самопальная OLAP-система? Те, с которыми я знаком, хранят данные в базе в "специально подготовленных плоских таблицах". _JK>читай внимательно — всю ветку — те с которыми ты знаком которые хранят в "специально подготовленных плоских таблицах" в оракле — не справляются с нагрузкой.
Позволь усомнится, ok? Пока ты не приведешь, как именно вы это делали в ORACLE, не поверю. Плоские таблицы большого размера ORACLE читает не медленнее, чем ты бы читал бинарные файлы (создай динамический курсор, пропиши хинты для однонаправленного чтения без блокировок, и наслаждайся). Речь о том, как и где вы организовали собственно вычисления, обычно тормоза в этом кроются, а не в скорости зачитки плоских таблиц из ORACLE. Кстати, когда ваша OLAP система будет периодически пересчитывать OLTP-данные и менять эти ваши "плоские файлы", то за счет фрагментации диска при нормальной нагрузке на сервак твое чтение бинарных файлов через OS будет серьезно "сливать" зачитке плоских таблиц из ORCALE, если речь действительно идет о гигах данных. Тема отдельная и весьма серьезная.
_JK>в нашей системе НЕ ИСПОЛЬЗУЕТСЯ НИКАКИХ СТОРОННИХ ПРОДУКТОВ ВООБЩЕ (не считая ASP.NET для веб клиента)
Да это стало понятно довольно быстро, непонятно твое желание тыкать носом во что-то оппонентов. Ирония в том, что ты пытался отослать меня к изучению OLAP, хотя ваша самопальная система из OLAP взяла м-м-м... черезчур общую идею.
_JK>>> не говори того чего не знаешь еще раз — ознакомся с тем что такое OLAP...
V>>После подобных выпадов всегда охота поинтересоваться каков возраст собеседника. А то может получиться так, что на время тратится на самоуверенного студента. _JK>если очень интересно — 26.
Вот оставил твой выпад из предыдущего поста, чтобы он был на одной странице с цифрой 26... в надзидание.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, _JoKe_, Вы писали:
V>>>Да ну? У вас самопальная OLAP-система? Те, с которыми я знаком, хранят данные в базе в "специально подготовленных плоских таблицах". _JK>>читай внимательно — всю ветку — те с которыми ты знаком которые хранят в "специально подготовленных плоских таблицах" в оракле — не справляются с нагрузкой.
V>Позволь усомнится, ok? Пока ты не приведешь, как именно вы это делали в ORACLE, не поверю. Плоские таблицы большого размера ORACLE читает не медленнее, чем ты бы читал бинарные файлы (создай динамический курсор, пропиши хинты для однонаправленного чтения без блокировок, и наслаждайся). Речь о том, как и где вы организовали собственно вычисления, обычно тормоза в этом кроются, а не в скорости зачитки плоских таблиц из ORACLE. Кстати, когда ваша OLAP система будет периодически пересчитывать OLTP-данные и менять эти ваши "плоские файлы", то за счет фрагментации диска при нормальной нагрузке на сервак твое чтение бинарных файлов через OS будет серьезно "сливать" зачитке плоских таблиц из ORCALE, если речь действительно идет о гигах данных. Тема отдельная и весьма серьезная.
полный бред.., во первых на одинаковом железе НИКОГДА ORACLE не прочитает большую плоскую таблицу быстрее чем её-же грамотно прочитать из плоского файла. не забывай о том что OLAP не занимается чтением больших таблиц и выводом их на экран, данные группируются, аггрегируются, фильтруются и много чего еще.
_JK>>в нашей системе НЕ ИСПОЛЬЗУЕТСЯ НИКАКИХ СТОРОННИХ ПРОДУКТОВ ВООБЩЕ (не считая ASP.NET для веб клиента)
V>Да это стало понятно довольно быстро, непонятно твое желание тыкать носом во что-то оппонентов. Ирония в том, что ты пытался отослать меня к изучению OLAP, хотя ваша самопальная система из OLAP взяла м-м-м... черезчур общую идею.
как можно говорить с таком стиле о продукте который ты не видел.? ты знаешь какая там идея? что он делает? как? с какой скоростью? у тебя есть сравнительная характеристика с аналогами?
_JK>>>> не говори того чего не знаешь еще раз — ознакомся с тем что такое OLAP...
V>>>После подобных выпадов всегда охота поинтересоваться каков возраст собеседника. А то может получиться так, что на время тратится на самоуверенного студента. _JK>>если очень интересно — 26.
V>Вот оставил твой выпад из предыдущего поста, чтобы он был на одной странице с цифрой 26... в надзидание.
короче разговор окончен, говорить не о чем, что такое OLAP, cub, dimension, fact, какие строятся в таких системах отчеты, как они выглядят, задаются, считаются, ты знаешь на уровне — "прочитал статью что такое олап", системы такие ты не разрабатывал с проблемами не сталкивался. поэтому эту тему с тобой обсуждать нет смысла.
Здравствуйте, _JoKe_, Вы писали:
_JK>не забывай о том что OLAP не занимается чтением больших таблиц и выводом их на экран, данные группируются, аггрегируются, фильтруются и много чего еще.
Cами по себе фильтруются?
_JK>>>в нашей системе НЕ ИСПОЛЬЗУЕТСЯ НИКАКИХ СТОРОННИХ ПРОДУКТОВ ВООБЩЕ (не считая ASP.NET для веб клиента)
V>>Да это стало понятно довольно быстро, непонятно твое желание тыкать носом во что-то оппонентов. Ирония в том, что ты пытался отослать меня к изучению OLAP, хотя ваша самопальная система из OLAP взяла м-м-м... черезчур общую идею.
_JK>как можно говорить с таком стиле о продукте который ты не видел.? ты знаешь какая там идея? что он делает? как? с какой скоростью? у тебя есть сравнительная характеристика с аналогами?
Ну ты же отослал меня к OLAP, правильно? Назначение OLAP — это хранение превычесленных данных по интересующим срезам с целью мгновенного получения отчетов. Неотъемлимой частью OLAP — является еще куча индексов в актуальном (по статистике) состоянии. Нафига читать гиг данных, если можно воспользоваться индексами и зачитать пару кил всего (при вычислениях с фильтрацией). Самописную систему имеет смысл писать только в том случае, если не нужны услуги базы данных, а именно: индексация, поддержание бинарных страниц в оптимальном порядке, адекватная по времени фильтрация из очень больших наборов.
Вы говорите, у вас там 4 гига очень шустро читаются. Ну во первых, 4 гига OLAP-данных, это сущие копейки. Во вторых, устрой стресс-тест, и посмотри, как у вас сканируется все 4 гига инфы при сотне одновременных сеансов вычислений твоих отчетов. Вопрос на засыпку, а для построения отчета точно нужны все 4 гига? А вы что, не храните предвычесленные данные, как в обычнфх OLAP? У меня в OLAP любые отчеты строились мгновенно, именно из-за того, что отчеты строятся не по сырым данным, а по предвычисленным, и по срезам, например, за день, за месяц, за год, по продавуам, по точкам, по отделам, по фирмам и т.д.. Как вы умудрились завалить Оракл, хрен его знает. И еще даешь советы "пойти почитать про OLAP". Давай сюда свою задачу, и мы посмотрим, что вы там такое навертели, что Оракл ушел в даун.
Если же вдруг выяснится, что вы все делали правильно, и даже почитали про OLAP перед этим, и все-равно ваша система делает все что надо ОЛАПу лучше Оракла — немедленно в очередь за Нобелевской Премией. Кроме шуток. Я прямо сейчас звоню знакомым в Штаты, и вашу систему покупают на корню вместе с разработчиками, столами и ковриками от мышей.
_JK>короче разговор окончен, говорить не о чем, что такое OLAP, cub, dimension, fact, какие строятся в таких системах отчеты, как они выглядят, задаются, считаются, ты знаешь на уровне — "прочитал статью что такое олап", системы такие ты не разрабатывал с проблемами не сталкивался. поэтому эту тему с тобой обсуждать нет смысла.
Как раз-таки несколько наоборот. Просто я отношусь ко всему этому очевидно "легче" тебя, ибо скоро лет 10 как впервые с этой темой столкнулся. А ты еще весь в своей важности, ИМХО (судя по тону предыдущих писаем). Ну так будет озвучена задача которая валит Оракл, или мы только заочно круты? Кстати, не забудь рассказать, как вы данные в своем самописном ОЛАПе обновляете.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, _JoKe_, Вы писали:
_JK>>не забывай о том что OLAP не занимается чтением больших таблиц и выводом их на экран, данные группируются, аггрегируются, фильтруются и много чего еще.
V>Cами по себе фильтруются?
_JK>>>>в нашей системе НЕ ИСПОЛЬЗУЕТСЯ НИКАКИХ СТОРОННИХ ПРОДУКТОВ ВООБЩЕ (не считая ASP.NET для веб клиента)
V>>>Да это стало понятно довольно быстро, непонятно твое желание тыкать носом во что-то оппонентов. Ирония в том, что ты пытался отослать меня к изучению OLAP, хотя ваша самопальная система из OLAP взяла м-м-м... черезчур общую идею.
_JK>>как можно говорить с таком стиле о продукте который ты не видел.? ты знаешь какая там идея? что он делает? как? с какой скоростью? у тебя есть сравнительная характеристика с аналогами?
V>Ну ты же отослал меня к OLAP, правильно? Назначение OLAP — это хранение превычесленных данных по интересующим срезам с целью мгновенного получения отчетов. Неотъемлимой частью OLAP — является еще куча индексов в актуальном (по статистике) состоянии. Нафига читать гиг данных, если можно воспользоваться индексами и зачитать пару кил всего (при вычислениях с фильтрацией). Самописную систему имеет смысл писать только в том случае, если не нужны услуги базы данных, а именно: индексация, поддержание бинарных страниц в оптимальном порядке, адекватная по времени фильтрация из очень больших наборов.
просто балдею какая умная мысль V>зачитать пару кил всего (при вычислениях с фильтрацией).
скажи пожалуйста а как ты будешь определять по фильтру какие пару кил тебе нужны????
я просто смотрю счас программист хороший пошел он думает что база данных это просто экстрасенс какой то и "select from where bla bla bla" он волшебно за один такт выполняет.
V>Вы говорите, у вас там 4 гига очень шустро читаются. Ну во первых, 4 гига OLAP-данных, это сущие копейки. Во вторых, устрой стресс-тест, и посмотри, как у вас сканируется все 4 гига инфы при сотне одновременных сеансов вычислений твоих отчетов. Вопрос на засыпку, а для построения отчета точно нужны все 4 гига? А вы что, не храните предвычесленные данные, как в обычнфх OLAP?
я сказал что 4 гига — это только те данные которые нужны для построения отчета. читай внимательно. данных всего — в сыром виде без всяких индексов и всего oстального на данный момент ~15гиг.
по стресстесту — система если сотня сеансов одновременно то система одни и те же данные не будет читать несколько раз они все паралельно идут и при зачитке данных они идут в калькуляторы всех отчетов которым нужны.
V>У меня в OLAP любые отчеты строились мгновенно, именно из-за того, что отчеты строятся не по сырым данным, а по предвычисленным, и по срезам, например, за день, за месяц, за год, по продавуам, по точкам, по отделам, по фирмам и т.д.. Как вы умудрились завалить Оракл, хрен его знает. И еще даешь советы "пойти почитать про OLAP". Давай сюда свою задачу, и мы посмотрим, что вы там такое навертели, что Оракл ушел в даун.
данные обновляются раз в день и если строить предвычесленные данные и индексы по всем пространствам то они даже врядли досчитаются до конца раньше, чем придут новые данные к загрузке.
V>Если же вдруг выяснится, что вы все делали правильно, и даже почитали про OLAP перед этим, и все-равно ваша система делает все что надо ОЛАПу лучше Оракла — немедленно в очередь за Нобелевской Премией. Кроме шуток. Я прямо сейчас звоню знакомым в Штаты, и вашу систему покупают на корню вместе с разработчиками, столами и ковриками от мышей.
очень пафосно....
_JK>>короче разговор окончен, говорить не о чем, что такое OLAP, cub, dimension, fact, какие строятся в таких системах отчеты, как они выглядят, задаются, считаются, ты знаешь на уровне — "прочитал статью что такое олап", системы такие ты не разрабатывал с проблемами не сталкивался. поэтому эту тему с тобой обсуждать нет смысла.
V>Как раз-таки несколько наоборот. Просто я отношусь ко всему этому очевидно "легче" тебя, ибо скоро лет 10 как впервые с этой темой столкнулся. А ты еще весь в своей важности, ИМХО (судя по тону предыдущих писаем). Ну так будет озвучена задача которая валит Оракл, или мы только заочно круты? Кстати, не забудь рассказать, как вы данные в своем самописном ОЛАПе обновляете.
ну ну, прям похоже все наоборот.... ты столкнулся а наша контора в этом бизнесе уже 15 лет, я в ней работаю уже 6, и важность мне не к чему...
если ты думаешь что все так просто — привожу факты
наш главный заказчик перед вводом нашей системы арендовал большой компьютер со спец софтом, у него возникли проблемы что отчеты долго считаются, перейдя на нашу специально для него написанную систему, он получил огромные приумущества в гибкости и скорости. то что на БК считалось 4 часа стало считаться на обычном сервере за 4 минуты... первое время они даже не верили а думали что мы им специально заготовленные и заранее посчитанные репорты показываем, писают кипятком уже 5 лет, по их словам "на рынке нету даже близко таких решений по скорости и гибкости".
ЗЫ: можешь не отвечать, смысла в разговоре не вижу, больше доказывать ничего не хочу, вести разговор в этой ветке прекращаю.
_JK>скажи пожалуйста а как ты будешь определять по фильтру какие пару кил тебе нужны????
Например, в доке по MS SQL очень даже подробно описано, как он хранит данные, как индексы, и как по индексам выбирает данные. Дока настолько подробная, что вплоть до бинарных подрбностей описано, как хранятся и обрабатываются данные.
_JK>я просто смотрю счас программист хороший пошел он думает что база данных это просто экстрасенс какой то и "select from where bla bla bla" он волшебно за один такт выполняет.
Трудно понять, что ты имел ввиду, но если ты про индексы, то это как бы основы.
V>>Вы говорите, у вас там 4 гига очень шустро читаются. Ну во первых, 4 гига OLAP-данных, это сущие копейки. Во вторых, устрой стресс-тест, и посмотри, как у вас сканируется все 4 гига инфы при сотне одновременных сеансов вычислений твоих отчетов. Вопрос на засыпку, а для построения отчета точно нужны все 4 гига? А вы что, не храните предвычесленные данные, как в обычнфх OLAP? _JK>я сказал что 4 гига — это только те данные которые нужны для построения отчета. читай внимательно. данных всего — в сыром виде без всяких индексов и всего oстального на данный момент ~15гиг. _JK>по стресстесту — система если сотня сеансов одновременно то система одни и те же данные не будет читать несколько раз они все паралельно идут и при зачитке данных они идут в калькуляторы всех отчетов которым нужны.
V>>У меня в OLAP любые отчеты строились мгновенно, именно из-за того, что отчеты строятся не по сырым данным, а по предвычисленным, и по срезам, например, за день, за месяц, за год, по продавуам, по точкам, по отделам, по фирмам и т.д.. Как вы умудрились завалить Оракл, хрен его знает. И еще даешь советы "пойти почитать про OLAP". Давай сюда свою задачу, и мы посмотрим, что вы там такое навертели, что Оракл ушел в даун.
_JK>данные обновляются раз в день и если строить предвычесленные данные и индексы по всем пространствам то они даже врядли досчитаются до конца раньше, чем придут новые данные к загрузке.
Но как это возможно? Тогда надо на ковер тех, кто составлял вашу схему данных (к технолдогии этот вопрос уже никакого отношения не имеет). У меня при обновлении пересчитывались данные только за день, затем из уже пересчитанных данных за день пересчитывались месяц, а из месячных данных — год. Да, пришлось немного попотеть и ввести кое-где избыточность (т.н. "исторические" или "архивные" зеркала данных), чтобы при обновлениях данных не надо было пересчитывать за год целиком все транзакции. А пересчет итогов из промежуточных... это смешно, ибо в месяце не более 30 дней (а не сотен тысяч транзакций, понимаешь о чем речь?), а в году не более 12 месяцев (а не миллионы транзакций). А пространств тоже не многие тысячи, дай бог десятки в самой навороченной системе.
V>>Если же вдруг выяснится, что вы все делали правильно, и даже почитали про OLAP перед этим, и все-равно ваша система делает все что надо ОЛАПу лучше Оракла — немедленно в очередь за Нобелевской Премией. Кроме шуток. Я прямо сейчас звоню знакомым в Штаты, и вашу систему покупают на корню вместе с разработчиками, столами и ковриками от мышей. _JK>очень пафосно....
А сам почитай, что ты там написал. Ты же признал, по-сути, что ваша система обладает св-вами решения общего плана (раз вы динамически отчеты строите), и при этом круче ОРАКЛа на несколько порядков.
_JK>если ты думаешь что все так просто — привожу факты _JK>наш главный заказчик перед вводом нашей системы арендовал большой компьютер со спец софтом, у него возникли проблемы что отчеты долго считаются, перейдя на нашу специально для него написанную систему, он получил огромные приумущества в гибкости и скорости. то что на БК считалось 4 часа стало считаться на обычном сервере за 4 минуты... первое время они даже не верили а думали что мы им специально заготовленные и заранее посчитанные репорты показываем, писают кипятком уже 5 лет, по их словам "на рынке нету даже близко таких решений по скорости и гибкости".
Замечательно. Тогда почему вы до сих пор не побили ОРАКЛ, и всякое другое г-но?
У меня была похожая история. 1С перепроводила документы на одной из фирм по 20 мин и более. И никто ничего не мог сделать, ибо когда очень большая база ТМЦ и в средней накладной по тысяче строк, то 1С перепроводит документы очень долго. Я когда-то сделал им классическую систему типа клиент-сервер, полностью писанную на Transact SQL, т.е. никакой логики на клиенте не было... в общем, самые большие отчеты перепроводились менее 4 сек. Но рынок с такой "системой" я завоевать не мог, ибо не предоставлял никаких ср-в для автоматизации, ибо каждая их уникальная операция мною вручную на Transact SQL была описана, профайлена и вылизана. А таким макаром далеко не уедешь.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, _JoKe_, Вы писали:
_JK>>скажи пожалуйста а как ты будешь определять по фильтру какие пару кил тебе нужны????
V>Например, в доке по MS SQL очень даже подробно описано, как он хранит данные, как индексы, и как по индексам выбирает данные. Дока настолько подробная, что вплоть до бинарных подрбностей описано, как хранятся и обрабатываются данные. _JK>>я просто смотрю счас программист хороший пошел он думает что база данных это просто экстрасенс какой то и "select from where bla bla bla" он волшебно за один такт выполняет. V>Трудно понять, что ты имел ввиду, но если ты про индексы, то это как бы основы.
хорошо — для тех кто в танке....
допустим у тебя есть файл в котором лежат числа тебе надо сделать запрос
хочу все числа больше 10.
ты строишь индекс по возрастанию и получаешь из него быстро все числа больше 10 — ок
теперь тебе надо все четные числа
новый индекс — все ок.
а теперь числа оканчивающиеся на 0,
а теперь те из которых можно извлеч корень
а теперь только простые
... и т.д.
сколько ты индексов строить будешь?
(числа это только пример чтобы ты понял что невозможно все индексы построить иногда надо и все данные просмотреть чтобы фильтр наложить)
V>>>Вы говорите, у вас там 4 гига очень шустро читаются. Ну во первых, 4 гига OLAP-данных, это сущие копейки. Во вторых, устрой стресс-тест, и посмотри, как у вас сканируется все 4 гига инфы при сотне одновременных сеансов вычислений твоих отчетов. Вопрос на засыпку, а для построения отчета точно нужны все 4 гига? А вы что, не храните предвычесленные данные, как в обычнфх OLAP? _JK>>я сказал что 4 гига — это только те данные которые нужны для построения отчета. читай внимательно. данных всего — в сыром виде без всяких индексов и всего oстального на данный момент ~15гиг. _JK>>по стресстесту — система если сотня сеансов одновременно то система одни и те же данные не будет читать несколько раз они все паралельно идут и при зачитке данных они идут в калькуляторы всех отчетов которым нужны.
V>>>У меня в OLAP любые отчеты строились мгновенно, именно из-за того, что отчеты строятся не по сырым данным, а по предвычисленным, и по срезам, например, за день, за месяц, за год, по продавуам, по точкам, по отделам, по фирмам и т.д.. Как вы умудрились завалить Оракл, хрен его знает. И еще даешь советы "пойти почитать про OLAP". Давай сюда свою задачу, и мы посмотрим, что вы там такое навертели, что Оракл ушел в даун.
_JK>>данные обновляются раз в день и если строить предвычесленные данные и индексы по всем пространствам то они даже врядли досчитаются до конца раньше, чем придут новые данные к загрузке.
V>Но как это возможно? Тогда надо на ковер тех, кто составлял вашу схему данных (к технолдогии этот вопрос уже никакого отношения не имеет). У меня при обновлении пересчитывались данные только за день, затем из уже пересчитанных данных за день пересчитывались месяц, а из месячных данных — год. Да, пришлось немного попотеть и ввести кое-где избыточность (т.н. "исторические" или "архивные" зеркала данных), чтобы при обновлениях данных не надо было пересчитывать за год целиком все транзакции. А пересчет итогов из промежуточных... это смешно, ибо в месяце не более 30 дней (а не сотен тысяч транзакций, понимаешь о чем речь?), а в году не более 12 месяцев (а не миллионы транзакций). А пространств тоже не многие тысячи, дай бог десятки в самой навороченной системе.
не смотри со стороны того что ты когда то делал.... тут другая система со своей спецификой...
в системе тысячи юзеров каждый из которых имеет свои ограничения на данные задаваемые логическим выражением.
представляешь сколько надо агрегатов построить? и сколько времени это займет? причем этот фильтр на данные для юзера может изменится в любой момент.... что тогда все агрегаты пересчитывать? а когда отчеты строить? если система все время будет заниматься построением промежуточных данных.
есть еще много факторов почему нельзя и не получается строить аггрегаты, индексы и выполнять многие другие оптимизации, не думай что тут сидят такие прям идиоты которые 15 лет делают продукты в этой области и незнают базовой теории.
V>>>Если же вдруг выяснится, что вы все делали правильно, и даже почитали про OLAP перед этим, и все-равно ваша система делает все что надо ОЛАПу лучше Оракла — немедленно в очередь за Нобелевской Премией. Кроме шуток. Я прямо сейчас звоню знакомым в Штаты, и вашу систему покупают на корню вместе с разработчиками, столами и ковриками от мышей. _JK>>очень пафосно....
V>А сам почитай, что ты там написал. Ты же признал, по-сути, что ваша система обладает св-вами решения общего плана (раз вы динамически отчеты строите), и при этом круче ОРАКЛа на несколько порядков.
есть большая разница — оракл это база данных
а наша система это analytical processing в нее нельзя запросто данные добавить чтобы они тут же в расчетах начали учавствовать....
OLTP и OLAP немного разные вещи, и решают разные задачи.
ты вспомни с чего разговор начинался я сказал что правильное специализированное решение эффективней общего. вот и все.
наша система заточенная под обработку определенных данных для решения определенных задач, бьет по всем позициям оракл и любые другие продукты предназначенные для обработки абстактных данных
_JK>>если ты думаешь что все так просто — привожу факты _JK>>наш главный заказчик перед вводом нашей системы арендовал большой компьютер со спец софтом, у него возникли проблемы что отчеты долго считаются, перейдя на нашу специально для него написанную систему, он получил огромные приумущества в гибкости и скорости. то что на БК считалось 4 часа стало считаться на обычном сервере за 4 минуты... первое время они даже не верили а думали что мы им специально заготовленные и заранее посчитанные репорты показываем, писают кипятком уже 5 лет, по их словам "на рынке нету даже близко таких решений по скорости и гибкости".
V>Замечательно. Тогда почему вы до сих пор не побили ОРАКЛ, и всякое другое г-но?
давно уже в своей нише рынка побили и оракл и другое г-но., а насчет большего охвата это не ко мне существует еще маркетинг лоббирование и много чего еще чем я и остальная команда разработчиков не занимается.
вопрос из той же серии что и
-почему есть юникс и виндовс и один не бьет другого
-.net и java
-Intel и AMD
-pc и mac
-СШA & others
и т.д.
V>У меня была похожая история. 1С перепроводила документы на одной из фирм по 20 мин и более. И никто ничего не мог сделать, ибо когда очень большая база ТМЦ и в средней накладной по тысяче строк, то 1С перепроводит документы очень долго. Я когда-то сделал им классическую систему типа клиент-сервер, полностью писанную на Transact SQL, т.е. никакой логики на клиенте не было... в общем, самые большие отчеты перепроводились менее 4 сек. Но рынок с такой "системой" я завоевать не мог, ибо не предоставлял никаких ср-в для автоматизации, ибо каждая их уникальная операция мною вручную на Transact SQL была описана, профайлена и вылизана. А таким макаром далеко не уедешь.
ну это твои проблемы я не знаю почему ты пишешь программы на которых далеко не уедешь....
_JK>допустим у тебя есть файл в котором лежат числа тебе надо сделать запрос _JK>хочу все числа больше 10. _JK>ты строишь индекс по возрастанию и получаешь из него быстро все числа больше 10 — ок _JK>теперь тебе надо все четные числа _JK>новый индекс — все ок. _JK>а теперь числа оканчивающиеся на 0, _JK>а теперь те из которых можно извлеч корень _JK>а теперь только простые _JK>... и т.д. _JK>сколько ты индексов строить будешь?
Это для бизнес-системы такие параметры запросов?
Если уж на то пошло, и дейтсвительно по этим признакам часто выполняются сложные запросы (а только профайлер даст ответ на этот вопрос), то при положительном ответе профайлера я не просто индекс сделаю, если формула индекса сложная (например — "простые числа"), я сделаю избыточные битовые поля в OLAP, по одному на каждый интересующий сложный признак. Ну а по ним — индекс.
_JK>не смотри со стороны того что ты когда то делал.... тут другая система со своей спецификой... _JK>в системе тысячи юзеров каждый из которых имеет свои ограничения на данные задаваемые логическим выражением. _JK>представляешь сколько надо агрегатов построить? и сколько времени это займет? причем этот фильтр на данные для юзера может изменится в любой момент.... что тогда все агрегаты пересчитывать? а когда отчеты строить? если система все время будет заниматься построением промежуточных данных.
_JK>есть еще много факторов почему нельзя и не получается строить аггрегаты, индексы и выполнять многие другие оптимизации, не думай что тут сидят такие прям идиоты которые 15 лет делают продукты в этой области и незнают базовой теории.
Странно, насчет "задаваемым логическим выражением". А обычная модель раздачи списка грантов пользователям и группам? Ведь эта модель не спроста так популярна — она естественным образом ложится на реляционную базу и легко участвует в запросах (у меня так было). Т.е., хоть юзверей и сотни было, но уникальных наборов прав совсем не много (просекаешь?). Поэтому вовсе не накладно было все срезы хранить/пересчитывать, тем более что система прав участвует обычно в менее половины отчетов (т.е. для другой половины права действуют целиком на отчет, и принимается решение — можно показать такой-то отчет целиком, или нет). Даже если у вас все так специфично, хочешь сказать, что набор прав уникален для каждого юзера из тысячи? Как минимум это немного странно, я могу предположить такое только если у фирмы-клиента много "серого" бизнеса и есть потребность в сокрытии информации для соседствующих направлений собственной деятельности, очевидно вам приходится делить права не только горизонтально, но и вертикально, т.е. делить данные из каждой таблицы буквально построчно, так? Сталкивался я однажды с подобным. Встроенными ср-вами безопасности или аналогичными эмулируемыми такую задачу эффективно не решить, есть такое. Более-менее эффективно решается построчное разделение данных, если удасться все существующие права представить в виде однонаправленной иерархии и жестко пронумеровать их.
V>>У меня была похожая история. 1С перепроводила документы на одной из фирм по 20 мин и более. И никто ничего не мог сделать, ибо когда очень большая база ТМЦ и в средней накладной по тысяче строк, то 1С перепроводит документы очень долго. Я когда-то сделал им классическую систему типа клиент-сервер, полностью писанную на Transact SQL, т.е. никакой логики на клиенте не было... в общем, самые большие отчеты перепроводились менее 4 сек. Но рынок с такой "системой" я завоевать не мог, ибо не предоставлял никаких ср-в для автоматизации, ибо каждая их уникальная операция мною вручную на Transact SQL была описана, профайлена и вылизана. А таким макаром далеко не уедешь. _JK>ну это твои проблемы я не знаю почему ты пишешь программы на которых далеко не уедешь....
Дык, давно бросил. Если бы жил в большом городе, наверняка бы постоянно находились бы весьма уникальные и специфичные клиенты. А так приходится сейчас рыночные коробочные продукты клепать... Самый что ни на есть ширпотреб. При удачном раскладе уехать можно очень далеко.
_JK>>допустим у тебя есть файл в котором лежат числа тебе надо сделать запрос _JK>>хочу все числа больше 10. _JK>>ты строишь индекс по возрастанию и получаешь из него быстро все числа больше 10 — ок _JK>>теперь тебе надо все четные числа _JK>>новый индекс — все ок. _JK>>а теперь числа оканчивающиеся на 0, _JK>>а теперь те из которых можно извлеч корень _JK>>а теперь только простые _JK>>... и т.д. _JK>>сколько ты индексов строить будешь? V>Это для бизнес-системы такие параметры запросов?
V>Если уж на то пошло, и дейтсвительно по этим признакам часто выполняются сложные запросы (а только профайлер даст ответ на этот вопрос), то при положительном ответе профайлера я не просто индекс сделаю, если формула индекса сложная (например — "простые числа"), я сделаю избыточные битовые поля в OLAP, по одному на каждый интересующий сложный признак. Ну а по ним — индекс.
не выкидывай мои слова я тебе написал ЭТО ПРИМЕР! для бизнес данных совсем другие запросы, просто ты не знаешь специфику поэтому они тебе ни о чем не скажут
так вот я тебе и говорю невозможно построить все индексы по всем запросам.
_JK>>не смотри со стороны того что ты когда то делал.... тут другая система со своей спецификой... _JK>>в системе тысячи юзеров каждый из которых имеет свои ограничения на данные задаваемые логическим выражением. _JK>>представляешь сколько надо агрегатов построить? и сколько времени это займет? причем этот фильтр на данные для юзера может изменится в любой момент.... что тогда все агрегаты пересчитывать? а когда отчеты строить? если система все время будет заниматься построением промежуточных данных.
_JK>>есть еще много факторов почему нельзя и не получается строить аггрегаты, индексы и выполнять многие другие оптимизации, не думай что тут сидят такие прям идиоты которые 15 лет делают продукты в этой области и незнают базовой теории.
V>Странно, насчет "задаваемым логическим выражением". А обычная модель раздачи списка грантов пользователям и группам? Ведь эта модель не спроста так популярна — она естественным образом ложится на реляционную базу и легко участвует в запросах (у меня так было). Т.е., хоть юзверей и сотни было, но уникальных наборов прав совсем не много (просекаешь?). Поэтому вовсе не накладно было все срезы хранить/пересчитывать, тем более что система прав участвует обычно в менее половины отчетов (т.е. для другой половины права действуют целиком на отчет, и принимается решение — можно показать такой-то отчет целиком, или нет).
никого не волнует что, как и куда естественным образом ложится. заказчиков интерисует эффективное решение их проблем, и их не волнуют вопросы sql, срезов, моделей что и как в программе устроено.
я тебе про фому а ты мне про ерему....
я тебе говорю что делает заказчик и что ему надо...
я бы посмотрел что бы ты и кому продал, если бы тебе заказчик сказал мне нужен фильтр по данным на каждого юзера — у нас такой бизнес, а ты ему в ответ — "у вас бизнес не правильный вы роли введите у меня тогда система будет соответствовать моим представлениям об олап", да они тебя на ... пошлют.
пойми что есть и другие задачи кроме тех которые ты когда то решал.
V>Даже если у вас все так специфично, хочешь сказать, что набор прав уникален для каждого юзера из тысячи? Как минимум это немного странно, я могу предположить такое только если у фирмы-клиента много "серого" бизнеса и есть потребность в сокрытии информации для соседствующих направлений собственной деятельности, очевидно вам приходится делить права не только горизонтально, но и вертикально, т.е. делить данные из каждой таблицы буквально построчно, так?
я же тебе объясняю в олапе нет таблиц, ну нету у нас базы данных. данные специальным образом препарированы, нету и sql запросов. потому что V>Сталкивался я однажды с подобным. Встроенными ср-вами безопасности или аналогичными эмулируемыми такую задачу эффективно не решить, есть такое. Более-менее эффективно решается построчное разделение данных, если удасться все существующие права представить в виде однонаправленной иерархии и жестко пронумеровать их.
вот в этом месте ораклу очень тяжело.
и все таки не более-менее, а очень эффективно все это решается.
права есть на данные, на объекты, на действия. бизнес абсолютно нормальный. собирают данные и потом продают доступ в систему, в которой каждый юзер может анализировать данные из купленной им области. кроме того есть права на действия, на объекты, гранты на пользователей и на группы, много чего еще, некоторое из них тоже в расчетах учавствует, например скидки и т.п.
V>>>У меня была похожая история. 1С перепроводила документы на одной из фирм по 20 мин и более. И никто ничего не мог сделать, ибо когда очень большая база ТМЦ и в средней накладной по тысяче строк, то 1С перепроводит документы очень долго. Я когда-то сделал им классическую систему типа клиент-сервер, полностью писанную на Transact SQL, т.е. никакой логики на клиенте не было... в общем, самые большие отчеты перепроводились менее 4 сек. Но рынок с такой "системой" я завоевать не мог, ибо не предоставлял никаких ср-в для автоматизации, ибо каждая их уникальная операция мною вручную на Transact SQL была описана, профайлена и вылизана. А таким макаром далеко не уедешь. _JK>>ну это твои проблемы я не знаю почему ты пишешь программы на которых далеко не уедешь....
V>Дык, давно бросил. Если бы жил в большом городе, наверняка бы постоянно находились бы весьма уникальные и специфичные клиенты. А так приходится сейчас рыночные коробочные продукты клепать... Самый что ни на есть ширпотреб. При удачном раскладе уехать можно очень далеко.
вот теперь становится понятно. клепая ширпотреб очень тяжело оценивать уникальные решения, а хочется получить собсвенно то что в начале топика предлагают сделать.
только для клепания ширпотреба это уже давно есть....
пошел на sourceforge кода набрал, кое как соплями скрепил, и дальше начинается самое интересное — втюхивание этого добра лохам, путем запудривания мозгов.
только после того как пузырь доткомов лопнул такой бизнес уже тяжело вести... лохов все меньше никто не хочет деньги на ветер выбрасывать.
_JK>вот теперь становится понятно. клепая ширпотреб очень тяжело оценивать уникальные решения, а хочется получить собсвенно то что в начале топика предлагают сделать.
Кстати, наконец вернулись к теме топика после обсуждения конкретно твоего случая. Разумеется, ср-ва автоматизации как класс имеют право на жизнь только при условии их многократного применения, т.е. для целей широкого потребления.
_JK>только для клепания ширпотреба это уже давно есть.... _JK>пошел на sourceforge кода набрал, кое как соплями скрепил, и дальше начинается самое интересное — втюхивание этого добра лохам, путем запудривания мозгов.
Это ты из головы вариант приводишь, очевидно. Решение задачи должно соответствовать условиям той самой задачи. Если решение соответсвует условию, то это не втюхивание, а вполне добросовестный бизнес. Кстати, у нас и спор-то начался от того. что ты считаешь, буд-то все задачи уникальны. Я наоборот считаю, что классов задач удивительно мало. Даже абсолютно разные задачи строятся из удивительно одинаковых блоков.
_JK>только после того как пузырь доткомов лопнул такой бизнес уже тяжело вести... лохов все меньше никто не хочет деньги на ветер выбрасывать.
Он лопнул не от плохого качества сайтов. Кстати, качество сайтов того времени до сих пор гораздо выше качества российских сайтов времени настоящего. Особенно это проявляется там, где приходится возвращаться и уточнять данные.
Так вот, доткомы лопнули от неготовности рынка, т.е. потребителей, этими доткомами пользоваться. Неожиданно выяснилось (ну надо же!!! ), что каждый отдельный чел регулярно посещает лишь очень ограниченный круг сайтов. От того в бизнесе доткомов теперь покупают не столько компании, сколько бренды, т.е. URL-и. Если кто и покупает компании, дык только лишь с целью покупки раскрученного URL-я.
К некачественному "лабанию" сайтов провал доткомов отношения не имеет. Да, многие непрограммисты выучили PHP, но ты просто не в курсе как там на западе делают сайты. Там десятки человек над одним сайтом работали, плюс жесточайший QA. Это только у нас сайты делаются 1-3-мя разработчиками, что сразу видно по качеству.
В общем, то, что задача решается легко (как это было на PHP), не говорит о том, что задача легкая. Просто эта задача может оказаться типовой и уже решенной и вылизанной многократно, от того легко повторяемой. Ведь эти самые "кухарки на PHP" именно этим и занимались — использовали готовые, вовсе не ими разработанные блоки. Вполне нормальное явление, особенно если эта "кухарка" как раз-таки является прикладным спецом не в программировании, а в той области, для обслуживания которых лепится сайт. Тут надо знать и понимать еще одну тонкость доткомов того времени: исполнителей подбирали конкретно под сайт, что немаловажно. Это у нас еще как-то очень статичный народ, и переход из фирмы в фирму — целое дело. Как побочный эффект — запросто могут уйти посреди проекта ибо разницы не делают.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[35]: Как вам задумка, а?
От:
Аноним
Дата:
05.01.07 15:00
Оценка:
ну так и где сие чудо ?!?!?!
или ниче не будет ?
и вобще че тема умерла...
Здравствуйте, Аноним, Вы писали:
А>Есть очень интересная задумка, призванная серьёзно облегчить жизнь программистам всего мира. А>Просьба, высказаться "за" или "против". Ну и так просто мнения пишите. А>Итак по порядку:
А>Тип: объектно-ориентированная среда разработки А>Платформа: .NET А>Компилятор: встроенный C# А>Цель 1*: абстракция от кода на каком-либо языке А>Цель 2**: отсутствие ошибок компиляции А>Цель 3***: устранение многих логических ошибок, таких как разорванные связи А>Цель 4*: более быстрая разработка приложений А>Результат: исполняемый образ .NET
А>* достигается за счёт сбора программы не из исходного кода, а из предопределённых элементов А>часть элементов является элементами алгоритма (циклы, условия, вызов метода и т.п.), но другая (бОльшая) часть является более высокоуровневыми элементами, которые реализуют в себе несколько других того же или более низкого уровня.
А>** достигается за счёт того, что исходный код, который будет скомпилирован, пишется не программистом, а генерируется ядром среды на основе структуры программы, заданной программистом. А>понятно, что этот код всегда будет правильным.
А>*** перед компиляцией и генерацией кода, структура приложения, собранная программистом из преопределённых элементов, будет проверяться на валидность и на бессмысленость. А>поскольку среда является объектно-ориентированной, это значит, что в ней все элементы (класс, структура, метод, цикл и т.д.) в ядре представленны объектами. А>например, если мы имеем метод method1, в котором есть инструкция вызова метода method2, то инструкция передставлена объектом, имеющим ссылку на method2, т.о. если программист впоследствии изменит имя метода method2 на method13, то никакой ошибки компиляции не будет, т.к. в инструкции сидит ссылка и инструкция, когда генерирует код, берёт имя метода по ссылке и оно оказывается method13. А>это всего лишь один пример, хотя на самом деле такая схема построения программ имеет много других преимуществ.
А>Самое главное — не надо будет тратить время на строчки кода. Потому что есть много готовых элементов, и программу можно составлять даже мышкой.
А>Эта среда планируется в будущем как если не замена, то серьёзная альтернатива Visual Studio. А>Кстати, модель кода (языка) будет содержать все элементы языка C# (for, foreach, is, as, switch, if, int, bool, и другие), так что перейти на эту среду смогут все те, кто уже знаком с C# или хотя бы с платформой .NET.
А>Если есть вопросы — задавайте.
А>А теперь критику и мнения в студию!
Мудро все как-то. С другой стороны, если посмотреть, то уже многое из этого есть. В той же VS можно многое делать визуально. Вопрос только в наличии таких компонент.Можно, конечно, попытаться визуализировать алгоритм, но от этого алогоритмических ошбок не избежать. Мало того, для визуализации программы и ее структуры можно пользоваться реверс инжинирингом в UML.
Поэтому, мне кажется, что нужно просто подобрать удобные продукты и эффективно их использовать.
Re: Как вам задумка, а?
От:
Аноним
Дата:
30.01.07 06:19
Оценка:
Ну и где этот чуду-программист? Так "хочется посмотреть в его честные глаза". Надо будет запомнить эту ссылку и раздавать всем создающим компонент TProgrammer.
ЗЫ Да простят меня за флуд.
Здравствуйте, kpomka, Вы писали:
K>ну так и где сие чудо ?!?!?! K>и вобще че тема умерла...
Тема не умерла. Просто мне как автору этого чуда очень сложно писать всё одному. Охотников и энтузиастов мне помогать так и не нашлось.
K>или ниче не будет ?
Будет. Но когда — вот это для меня самого большой вопрос.
Соглашусь с предыдущим оратором — БРЕД.
Для того чтобы сделать нечто подобное надо как минимум реализовать искусственный интеллект. То есть задача сводится к воплощению в жизнь идей из фильма "Матрица".
В названии проекта однозначно должно быть использовано слово "русский".
Да пребудет с тобою сила
Re: Как вам задумка, а?
От:
Аноним
Дата:
29.03.07 13:03
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Есть очень интересная задумка, призванная серьёзно облегчить жизнь программистам всего мира. А>Просьба, высказаться "за" или "против". Ну и так просто мнения пишите.
На самом деле существуют предметные области, где как раз и применяется визуальное программирование. Например, программирование логических контроллеров ведется на языках
Step7. Вообщем я как раз защищаю кандидатскую примерно по этой теме, поэтому сразу скажу, что идея нормальная, но геморойна в реализации
1.1.4 stable rev. 510
)
, не получится то ....
