Есть очень интересная задумка, призванная серьёзно облегчить жизнь программистам всего мира.
Просьба, высказаться "за" или "против". Ну и так просто мнения пишите.
Итак по порядку:
Тип: объектно-ориентированная среда разработки
Платформа: .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.
Здравствуйте, Аноним, Вы писали:
А>А теперь критику и мнения в студию!
в кратце?! БРЕД. чем все выше изложенное отличается от присловутой концепции 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: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>Это не есть достоинство, скорее недостаток.
Автоматизация в разумных пределах, конечно.
Re[4]: Как вам задумка, а?
От:
Аноним
Дата:
15.09.06 13:44
Оценка:
Здравствуйте, alku, Вы писали:
A>2) примеры: в школе не учил диаграмки для рисования алгоритмов?! теперь есть такое и у макрософта Workflow Framework (правда задачи слегка посложнее решает), UML диаграммы — как язык программирования?!
про UML знаю
"UML диаграммы — как язык программирования?!" — а чем плохо????
Здравствуйте, <Аноним>, Вы писали:
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 не пользуюсь, что уж говорить о более крупных блоках? В современных языках средств реюза кода более чем достаточно.
А>это вставка кусочков кода туда, где они нужны в данном коде
Давай пример что ли приведи.
А>за счёт всей моей концепции и всего того, что изложено выше.
Два мнения уже есть.
Оба человека до конца не поняли, что это будет.
Один из них даже начал прикалываться. Про грузинов что-то рассказывать...
Интересно было бы услышать ещё мнения.
Может быть найдутся люди, мыслящие в одном со мной направлении.
И ещё.
Если вы не будете использовать мою среду разработки, это не значит что её не будут использовать ваши конкуренты.
Каждый выберет, то что, удобней и то, на чём быстрее.
Здравствуйте, <Аноним>, Вы писали:
А>Если вы не будете использовать мою среду разработки, это не значит что её не будут использовать ваши конкуренты. А>Каждый выберет, то что, удобней и то, на чём быстрее.
А>Оба человека до конца не поняли, что это будет. А>Один из них даже начал прикалываться. Про грузинов что-то рассказывать...
Возможно ты просто непонятно объясняешь.
А>Интересно было бы услышать ещё мнения. А>Может быть найдутся люди, мыслящие в одном со мной направлении.
Найдутся, скорее всего. Я видел несколько попыток реализовать автопостроение программы по некой диаграмме. И видел, чем они заканчиваются. В большинстве случаев мало-мальски сложный алгоритм гораздо удобней обрабатывать и представлять в виде текста. Впрочем, я знаю одну узкоспециализированную программу, где проще задавать исходные данные в виде диаграммы, а уж по этой диаграмме строится исходник на требуемом языке. По крайней мере, автор утверждает, что ему проще Если пришлешь какой-нибудь контакт, я готов отправить его автору.
А>Если вы не будете использовать мою среду разработки, это не значит что её не будут использовать ваши конкуренты. А>Каждый выберет, то что, удобней и то, на чём быстрее.
Здорово! Значит некоторым количеством конкурентов у нас станет меньше
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, 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[3]: Как вам задумка, а?
От:
Аноним
Дата:
16.09.06 13:33
Оценка:
Здравствуйте, Марк, Вы писали:
А>>Оба человека до конца не поняли, что это будет. А>>Один из них даже начал прикалываться. Про грузинов что-то рассказывать... М>Возможно ты просто непонятно объясняешь.
Возможно. Уж как умею.
А>>Интересно было бы услышать ещё мнения. А>>Может быть найдутся люди, мыслящие в одном со мной направлении. М>Найдутся, скорее всего. Я видел несколько попыток реализовать автопостроение программы по некой диаграмме. И видел, чем они заканчиваются. В большинстве случаев мало-мальски сложный алгоритм гораздо удобней обрабатывать и представлять в виде текста. Впрочем, я знаю одну узкоспециализированную программу, где проще задавать исходные данные в виде диаграммы, а уж по этой диаграмме строится исходник на требуемом языке. По крайней мере, автор утверждает, что ему проще Если пришлешь какой-нибудь контакт, я готов отправить его автору.
Я не уверен, что у того человека точно такая же мысль, как и у меня, но что-то похожее вроде...
Здравствуйте, <Аноним>, Вы писали:
А>Проект мой начался ещё год назад. Начался с того, что мне лично ***надоело набирать эти грёбанные строчки кода***!!! Поэтому я решил сделать некую среду, которая бы позволяла в глаза не видеть этот код, а просто делать программу мышкой по кусочкам. Ну вводить с клавы только там... имена для понятия смысла объекта, да параметры объектов...
А>Вот вам не надоело набирать код? А>В моей среде не только "диаграммы", как вы их называете, будут, но также графически будут представлены и сами тела методов.
Ты бы скиншотов или концептуальных рисунков каких-нибудь выложил. Может проще было бы обеснять.
