Вместо прояснения читай коменты, проект рождается в них.

Именно прочитанные (весь тред) коменты и сподвигли написать о том что ничего не ясно.

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

Да тут 95% работы - «предоставить возможность мышкотыкания»

Я не говорил что это ЯП

А давайте не спорить о технологихя и способах реализации, а о функционале и необходимах фичах. Предлагаю ТСу в первом посте сделать список, куда будет вносится функционал предложенный в процессе обсуждения. Это конечно если вы хотите чтобы хоть что-то получилось. А то вы еще даже представления не имеет о том, чего хотите, а уже спорите на питоне писать или на лисп и делать вебгуи или нет.

Я не говорил что это ЯП

Не важно. ДРАКОН для проектирования тупо не подходит. Это всего лишь сраные картинки для записи алгоритмов, которые уже на уровне быстрой сортировки воспринимаются тяжелее чем большинство нормальных ЯП (языков программирования).

ТС, для нормального проектирования достаточно доски и маркера. Но, уж хочется инструмента: 1) нотация должна быть неформальной(неким каркасом с минимальным количеством элементов) 2) нотация должна быть расширяемой 3) необходимы инструменты для работы команд над проектом 4) в каждой диаграмме надо дать возможность вставлять куски из других диаграмм проекта, изменяющиеся и с ссылкой.

В общем вот мои идеи, на тред подпишусь. И в 2 вечера годнота не получится даже у лисперов:-)

ДРАКОН для проектирования тупо не подходит.

Почему нет? Оно, собственно, ничем не отличается от типичной блок-схемы. Как один из возможных вариантов сойдет.

Предлагаю ТСу в первом посте сделать список, куда будет вносится функционал предложенный в процессе обсуждения.

На ЛОРвики, или сразу на битбакете?

Ну все, девелопмент можно смело переименовывать в «проэкты» по типу геймдева. Ладно бы еще смеялись над подобными топиками, так это всерьез обсуждается.

Что тебе не понравилось? :)

А давайте создадим нормальную опенсурсную систему проектирования ПО?

У автора весьма причудливое представление о нормальном.

По сравнению с тем что сейчас есть под линукс - вполне нормальное =)

а проблема UML в серьезной избыточности и неочевидности.

А проблема UML в том, что даже при серьёзной избыточности он всё равно прибит гвоздями к яве и её реализации ООП, и почти неюзабелен за её пределами.

кстати, вместо ООБД для хранения можно использовать Camlistore - CAM, content-addressable memory типа Git блобов и коммитов или Venti/Fossil из Plan 9

С пункта 2 по 9 иди на хабр за ответами.

одно дело если ты хочешь для себя напоиграться проект похакать что-нибудь, и другое, если рассчитываешь получить хороший, годный инструмент.

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

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

для себя хотя бы определись.

Чуть позднее соберу свои мысли по поводу проекта и размещу сдесь.

ок, давай — буду следить за топиком. и да, ты так и не ответил «зачем?».

почему надо писать свой велосипед вместо того, чтобы пользоваться готовым Dia, например?

почему вообще надо своё, чего не хватает в готовых аналогах?

чем твой велосипед будет лучше/удобнее/понятнее/эффективнее/полезнее?

ДРАКОН для проектирования тупо не подходит.

хотелось бы аргументов. что такое ДРАКОН, с твоей точки зрения (ИМХО: это визуальный язык программирования, ЯП). почему не подходит для проектирования — что нужно для проектирования чего нет в ДРАКОНе.

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

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

это не просто «сраные картинки», это «эргономичные сраные картинки». и это всё меняет.

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

а это уже алгебра опрераций визуального языка программирования.

паттерны, по-вашему.

весело же. а вдруг на ЛОРчике всё станет внезапно по серьёзному, и неосиляторы по заявкам осилят «реалтайм кодинг компо»?

ну претензии у UML 2.0 были на моделеориентированность и генерацию артефактов следующих из предыдущих, пока набора диаграмм не станет внезапно достаточно до «исполняемой модели».

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

в то время как тот же SWITCH-автомат, ДРАКОН, BON — выполняют обещания по генерации и обработке таких моделей автоматизированно.

и почти неюзабелен за её пределами.

теоретически для этого можно юзать «стереотипы» и «ассоциации». на практике хз насколько это понимабельно, всё равно массы знают не больше 2-3 диаграмм из всего UML 2.0

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

чем неудобны? что предлагается вместо этого?

А давайте попробуем обсдудить и создать ПО для переноса мыслей из головы на бумагу?

давай. какой функционал требуется ? какую задачу будет решать ПО?

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

почему именно IDEF0/SADT? (ну да ладно, мало ли)

что именно лишнее и почему?

каких финтифлюшек добавить и почему?

подготовь инфраструктуру, составь ТЗ, раззбей задачу на milestone

пистон не знаю, но относительно знаю js и пых

Да.. в девелопменете ведется изучение предметной области инструмента программирования - разве так можно! Эх.. жаль geekless не дожил, надо кастануть унылого beastie, скатывание останавливать нельзя!

В опенсурсе нет нормальной рисовалки диаграмм

Как вам идея?

Так что идея никакая.

ps. dia - за норму не тянет, также как и куча аналогов

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

векторный редактор

на самом деле не только редактор, но и просмоторщик

А вообще хочется, наверно, визуальный текстовый редактор, кодогенерацию (или хотя бы генерацию юнит-тестов).

Еще фича: область, на которую можно сослаться, и обсуждения области.

Касаемо бэкенда - это можно сделать плагином к redmain.

Предлагаю JSON

А может надстройкой к svg?

Я тот первый анон, который за доску и маркер.

Оно, собственно, ничем не отличается от типичной блок-схемы

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

Проектирование, как процесс, ты ничем не облегчишь. Это все то же сидение с карандашом и черновиком из принтера или обсуждение за бордой, или обедом, или в курилке.

Максимум что можно сделать — облегчить передачу *готового* (в каком либо виде) знания другим членам команды. То есть тупо очередной генератор картинок (просто удобней остальных). Такие дела.

хотелось бы аргументов. что такое ДРАКОН, с твоей точки зрения (ИМХО: это визуальный язык программирования, ЯП)

Именно так я себе его и представляю.

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

Хотя там еще есть что-то про моделирование, но примеров не встречал, поэтому эта часть для меня полная НЕХ.

Лучше ориентироваться на https://www.lucidchart.com/

Тогда уж Flow-based programming.

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

ну, сочетая с системным подходом: «чёрный ящик» с абстракциями можно как-то выкрутиться, хотя согласен, достаточно ли их — тот ещё вопрос, практический.

в ДРАКОНе есть встроенный способ разбития на подабстракции: вызываемые процедуры, и параллельные процессы, процессы реального времени (с ограничением по времени, таймерами, и т.п.). сейчас чего-то мутят для дальнейшего развития параллельных процессов, чтобы как-то обойти необходимость GOTO в кодогенераторе (а то в Оберон-2 например GOTO не поддерживается; хотя там и исключения не поддерживаются).

ИМХО, если им удастся придумать нормальную абстракцию для этого, будет WIN (а ещё лучше, что-то вроде условий и перезапусков из CL)

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

то есть, абстракция процедурного, структурного программирования. для компонентного/модульного программирования типа Oberon-2, Component Pascal, Modula-2 вполне достаточно.

а далее — системный подход и чёрные и белые ящики.

хотя да, для ООП с паттернами только подпрограмм может быть недостаточно.

Хотя там еще есть что-то про моделирование, но примеров не встречал, поэтому эта часть для меня полная НЕХ.

примеры есть в книжках и что-то на форумах — пытаются применять для АСУТП, программирования микроконтроллеров и т.п.