мини IDE

[v-t-l]

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

http://ru.wikipedia.org/wiki/%D0%94%D0%A0%D0%90%D0%9A%D0%9E%D0%9D_%28%D1%8F%D0%B7%D1%8B%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%29

[stikriz]

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

Добавлено спустя 3 минуты 52 секунды:
- http://commons.wikimedia.org/wiki/File:Dutch_cryo_Moscow.png?uselang=ru - посмотрите на картинку, и объясните мне принципиальное отличие от обычной блок-схемы.

Добавлено спустя 13 минут 6 секунд:
Вот пример "логики" и несказанной наглости:

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

На первом этапе — после изобретения структурного программирования и призыва Эдсгера Дейкстры: «оператор go to должен быть отменен в языках программирования высокого уровня»[28] — начался процесс исключения GOTO из вновь создаваемых языков. Сегодня имеется целый ряд языков без GOTO: Java, Python, Tcl, Модула-2, Оберон и др.

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

При этом открылись два обстоятельства. Транслятор из ДРАКОНа в целевой язык лучше всего делать с использованием GOTO, имеющемся в целевом языке. Если же оператор GOTO в целевом языке отсутствует, этот оператор приходится эмулировать.[29]

Это из википедии. Обратите внимание на логику: у дракона нет goto, но его нельзя транслировать без goto в целевом языке.
А теперь о нескромности: Было только два этапа развития языков: когда не было дракона и когда он появился

[Kemet]

1. Что они громоздки. Без большого монитора или большого принтера - они неприменимы.

Они разные.
Например, Р-схемы, разработанные в СССР довольно компактны

Код: Выделить всё

$===========================================$
!z := 1 TO 10                               !
!-------->$=================================$
i := 0   !j < 10    A[i] > A[j]            !
j := 1   !-------->$--------------->$----->!
                    !x := A[i]       !INC(i)
                    !A[i] := A[j]    !INC(j)
                    !A[j] := x       !
                    !                !
                    !--------------->!

[alexey38]

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

Судя по описанию Дракон создавался для специальных задач, насколько он там применяется или не применяется не знаю. Но скажу, что когда в свое время стал интересоваться книжками про ИТ-менеджмент в разработке ПО (у меня около 50 книжек на эту тему, хотя многие только мельком просмотрел). Так вот, там удивительная для меня вещь оказалась, американцы под военные и космические задачи столько бабла вбухивали в ИТ-отрасль, что там точно также целые институты страдали всякой фигней, изобретая всевозможные системы для лучшего программирования. Авторы честно пишут, что 90% гарантировано ушло в помойку, но все же отдельные идеи были не плохими. И количество перешло в качество, т.е. мы сейчас во многом сами используем побочный продукт американской оборонки, которая в части программирования очень много чего родила.

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

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

[stikriz]

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

Конечно. Компоненты - это развитие идеи черного ящика.

либо писать графические конфигураторы.

Это здравая, модная и перспективная идея. Правда, труднореализуемая эффективно для всех случаев жизни. Но, процессоры не стоят на месте, и эффективность растет, а за все надо платить, в конечном счете, эффективностью.

[sign]

Учитывая, что Дракон создавался, когда еще не было UML

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

Параджанов разработал замечательную систему. Тот, кто в ней не разобрался, путает её с обычными блок-схемами.
Дракон - это не блок-схемы. Это значительно большее. Но чтобы это понять, нужно изучать и врубаться в суть.

Что касается идеи гибридный языков типа Дракона

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

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

[stikriz]

Параджанов разработал замечательную систему.

Сначало я разобрался, потом, програмку для составления скачал, потом книжку просмотрел, т.к. читать этот бред невозможно.
Так вот, это блок-схемы. Как рисовать блок-схемы - это только правила. То, что из блок-схемы, якобы, но это совсем не так, можно получить код - это хорошо, если бы было правдой. К этому надо стремиться. В драконе же просто указывается какой набор инструкций (подпрограмма, например) будет выполняться, если на схеме есть вот такой квадратик. Это детский сад. Насчет высеров про мозг, про его изученость лично Параджановым, и про утомленность от сложностей жизни, могу сказать - покажите мне блок-схему текстового редактора, например, можно без поддержки разметки, и покажите, что это проще, чем на сях Тогда поговорим. Так что это именно инструкции. Отличная идея для составления инструкций, для выполнения тех или иных действий на случай тех или иных обстоятельств. Например, должностные инструкции - самое то, где это можно применять. Т.е. что мы видим? Взяли старющюю тему, прилепили бред про мозг и вредность мышления, выдали за ноу-хау. Так победим - это наш путь!

[vada]

Чего вы докопались до дракона? Его просто надо забыть как забыли первокарты.
Человек тут современную IDE для паскаля делает, а вы....

[stikriz]

А я боюсь, что он дракониху чтоб не сделал
Ну, ждем демки, так сказать.

Добавлено спустя 32 секунды:

как забыли первокарты

перФокарты

[vada]

Кстати, зачетная описка первокарты получилась. Такая недвусмысленная.

По теме. Если он туда хоть зачатки UML вставит, будет неплохо. Блок-схемы спорны, но тож сгодится.
На мой взгляд все нужно, и визуальное программирование, и UML, возможно, и блок-схемы ( с ними проще с заказчиком общаться).
Программист сам должен решать где каким инструментом удобнее пользоваться. Но автоматом генерировать код из блок-схем... пф... фигняс. Здрасти GOTO.

[alexey38]

Я бы сказал, что UML для описания структуры - это в 90% лишняя работа. Ясности не добавляет, зато куча громоздкости и формализма.

Описывать на блок-схемах (UML, Дракон и т.п.) алгоритм редактора текста - это глупость.
А вот элементы бизнес-логики или технологической логики - это наоборот хорошая штука. Только не надо путать инструкцию и бизнес-логику, т.к. большинство программеров этого сайта пишут визуализацию БД, то с бизнес-логикой у них туго (нет опыта).
Например, на такой удобно описывать алгоритм работы стиральных машин, т.е. места где много И, ИЛИ, НЕ логики, и эта логика связана не с программной (как в алгоритме редактора текста), а с внешним процессом (вне программы, вне компьютера).
Хорошие графические средства описания алгоритмов должны поддерживать еще и графические комментарии (например, картинка стиральной машины с указанием датчиков и кнопок управления), делающие графический алгоритм более понятным (т.к. стрелка с переменными будет визуально идти от датчика или кнопки). Вот такой бы гибридный язык над паскалем был бы полезным, и если он сгенерит GOTO то ничего страшного, ведь паскалевский код - это просто для информации, как и асмовский код, генерируемый компилятором.

[sign]

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

Любой язык программирования в конечном итоге есть набор инструкций для процессора.

покажите мне блок-схему текстового редактора, например, можно без поддержки разметки, и покажите, что это проще, чем на сях

Языки есть разные, под разные задачи.
Где то си хорош, а где-то пролог его обставит. А некоторые (молодцы) даже на Форте бацают!
И Дракону есть своя ниша.

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

Ещё раз повторю, вы просто не поняли, что есть такое Дракон.

[stikriz]

Я бы сказал, что UML для описания структуры - это в 90% лишняя работа.

Сразу скажу, что я сертифицирован по розе. Так вот, насколько я понял о чем Вы пытаетесь сказать, это совсем не так 100% UML описания классов идет в код, если есть генерация кода. Реализация - это отдельный вопрос, хотя, диагтаммы состояний могут пригодиться. Очень плохо с генерацией реализации, потому, что иначе диаграммы станут громоздскими.

А вот элементы бизнес-логики или технологической логики - это наоборот хорошая штука.

Щас насыплю соль на рану. В 1С, да в 1С есть такая штука - бизнеспроцессы, кстати, на блок-схемах, почти UML, так вот, там на каждый этап можно написать некий алгоритм. Сейчас, так как вещь новая, почти не используется. Так вот, пользователь видит блок-схему как ему действовать (диаграмма действий) в данном бизнес-процессе, и идет пошагово, выполняя действия: редактируя и создавая документы, нажимая кнопочки на формах, просто выбирая ответ. Все время видно на каком ты этапе сейчас находишься. Через механизм событий следующие этапы можно передавать следующим акторам. Вот это, то, что доктор прописал. Я такое делал на Дельфи. В виде мастера, как инсталлятор обычно интерфейсно. Пользователям нравится, особенно, когда тот, кто этим никогда не занимался, а надо. Потом, со временем будет некая структура в мозге, как одни документы соотносятся к другим, очередность и прочее, а перые сто лет, конечно, лучше иметь некую блок-схему.

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

Обидеть хотите? БД, как правило, и занимается именно бизнес-логикой, потому, что это называется, если ВЫ не знали, автоматизацией бизнес-процессов. Хотя, подозреваю, что многие очень начинающие программеры это делают интуитивно, не изучая классиков - методом тыка, шишек и как получиться

Любой язык программирования в конечном итоге есть набор инструкций для процессора.

Демагогией нравится заниматься? Подпрограмму, заранее оформленую от компиляции отличить не могем?

Языки есть разные, под разные задачи.

Язык должен быть полным. Дракон - не язык. Учите матчасть.

Дракону есть своя ниша.

Мне жаль тех несчастных, которым придется там в этой нише ютиться. Хотя, им же думать не надо? А дебилам везде хорошо одинаково

Ещё раз повторю, вы просто не поняли, что есть такое Дракон.

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

[Brainenjii]

Язык должен быть полным.

Да ну

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

Не представляю, насколько этот самый дракон может решить подобную задачу, но я бы не отказался от решения, подобного Pascal Script, но реализованного именно в виде диаграмм... Так чтобы "кинул на форму" компонент, a la, LazReport, настроил - и получил стандартный механизм редактирования пресловутой бизнес-логики на уровне GUI. А не плодил неуклюжих велосипедов.

[stikriz]

Вот, не хотел. Лучше бы вам всем любителям придурка Паранжанова заткнуться. И я бы помолчал, надеясь на разум читающих форум. Простите меня, автор невинной мини IDE...

Да ну

Ну, да

Автор. Назвать можно как угодно. Например, “технологический язык”, сокращенно “техноязык”.
Читатель. Все-таки непонятно: зачем менять устоявшуюся терминологию, к которой все привыкли? Чем вам не нравится название “язык программирования”?

Просто программирования. Вот, я бы хотел запрограммировать текстовый редактор на драконе, да так, чтобы мне было легто и просто и без помощи профессиональных программистов - они лишнее звено:

Они создают повышенный интеллектуальный комфорт, улучшают работу ума, повышают продуктивность труда. С их помощью вы научитесь легко и быстро, затратив минимум усилий, решать сложнейшие проблемы: проектировать сложную деятельность и бизнес-процессы, формализовать свои профессиональные знания и выполнять алгоритмизацию самостоятельно, без помощи программистов — по методу “Программирование без программистов”.

Т.е. писать программы не владея навыками программирования, т.е. писать алгоритмы без понимания алгоритмирования, т.е. писать хрен знает что как в анекдоте:
- Печатаю 50 000 знаков в секунду - хрень получается несусветная...
И еще,

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

Думать опасно для здоровья? Надо не думать!

. Сегодня необходимо создать не очередной язык для меньшинства, а язык для всех, который позволит укрепить слабое звено и улучшить умственную продуктивность большинства специалистов. Для этого нужно построить формальный или частично формальный язык, который был бы не “собачьим” или “птичьим”, а “человечьим” — общедоступным, удобным и понятным для каждого.

Это, видимо, привет нам всем. т.е. собакам и щукам? Щуки налево, собаки направо!

Можно ли повысить качество решений сложных и сверхсложных интеллектуальных проблем, необходимых для развития цивилизации, и одновременно защитить людей от опасных для здоровья умственных перегрузок? Как облегчить и улучшить работу человеческого ума? Увеличить продуктивность творческого мышления? Преобразовать трудные и непосильные задачи в легкие и посильные? Словом, превратить интеллектуальные муки-мученические во что-нибудь более достойное человека и даже приятное?

Конечно Параджанов знает как можно! Но, почему-то мне всегда нравилось решать непосильные задачи Видимо, ему больше нравится щеголять знанием решебников? Все фразы так или иначе дают понять, что думать сложно (тут он прав), но ненужно. И сразу вспоминается пресс без занятий спортом, стройность без усилий над собой по китайскому методу глотания червя... Кто-то верит в такое?

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

О! Не надо думать, а то станешь покойником... Всем срочно надо стать талантливыми пользователями, а не творческими личностями. Именно к этому нас призывал прошлый придурок от образования. Это в ответ на приезд Билли и его речи.
Это по существу. У Вас есть что ответить по существу, кроме заклинаний, типа Парнжанов придумал что-то новое. Может-ли дегенерат от образования придумать что-то полезное? НЕТ! он может только взять наработаный опыт прошлых поколений и присвоить себе. Никто не говорит, что блок-схемы - это зло. Все знают, что блок-схемы имеют свою нишу. Но, никто не имеет прав на Луну, тем более, дебилизм виден в разговорах о том, что програмисты не нужны и думать вредно. Это каждый решает для себя. Если ты полы моешь в офисе - это твой выбор, который не запрещает тебе думать и интересоваться, например, Мондельштамом, но это не значит, что все должны быть дебилами как ты, кто не интересуется ничем, и кому думать опасно для здоровья.

Добавлено спустя 22 минуты 24 секунды:

Так чтобы "кинул на форму" компонент, a la, LazReport, настроил - и получил стандартный механизм редактирования пресловутой бизнес-логики на уровне GUI. А не плодил неуклюжих велосипедов.

Выглядит так: рисуется схема бизнес-процесса. У каждой сущьности есть обработчики событий. В эих обработчиках можно писать код. Например, позвонил заказчик - бузнесс-процесс звонок заказчика. Запускаем. Форма: телефон, кто звонил, Контрагент. ОК - Данные заносятся в справочники и регистры. Кто, телефон - в регистр сведений, контрагент, если нет, то создается. если есть, то используется. Тема звонка, если заказ, создается заказ покупателя, если другое - другое. И т.д. Все время прохождения бизнес-процесса пользователь видит диаграмму и позицию где он находится.