Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>2. Вы привели привер ПЛОХОЙ графики.
ВП>3. Дракон-схема — это ХОРОШАЯ графика.
В 101 раз просим привести пример реального кода на ДРАКОНе.

Хотя бы в виде аналога десяти тысяч строк обычного кода. Это несколько месяцев работы обычного программиста на типичном коде.

А так вижу, что этот ДРАКОН используется очередными псевдоакадемическими бездарями чтобы мучать студентов.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, WolfHound, Вы писали:

WH>>Дракон-схема задает конечный автомат.
WH>>Если задача не сводится к конечному автомату, то дракон работать перестает.

V>При наличии рекурсий — в магазинный, т.е. превращается в машину Тьюринга.

А с каких пор pushdown automaton эквивалентен машине Тьюринга?

Здравствуйте, xvost, Вы писали:

X>И что — кто-то в графическом виде оперирует с dataflow больше чем 20-30 узлов? Не верю.

Дык, и в исходнике метода по-хорошему должно быть не более десятка-другого строк. Я же уже делал упор на декомпозицию и иерархию: то, что на одной схеме представлено "атомарным" блоком, на другой будет алгоритмом следующего уровня подробностей. Это полный аналог с иерархическими вызовами ф-ий/методов.


V>>Дракон — это мета-программирование само по себе. Другое мета-программирование будет другим, иногда принципиально другим. В том-то и дело, что метапрограммирование — это всегда некий трюк по выходу на новую степень абстракций. Графика — это лишь один из таких трюков, работающий из-за "врожденной" иерархичности элементов.

X>Слова знакомые, а мысль от меня ускользает....
X>Я, по свей наивности, всегда считал мета-программированием то, что выполняется на этапе компиляции.

Нет, само мета-программирование выполняется на этапе его программирования программистом.

Метапрограммирование — это процесс расширения семантики имеющегося инструмента, чтобы программировать затем целевую задачу (нас же целевая задача в итоге интересует, правда?) в терминах этой расширенной семантики. Как пример — макросы Лиспа, immediate слова Форта или шаблоны С++ при использовании специализаций (частичных в т.ч.). А в графике — это определение новых графических примитивов, в том числе параметрических, которые можешь считать полными аналогами макросов. Т.е. инструментарий библиотек/модулей и инструментарий макросов в случае графического инструмента сливается в один и тот же инструментарий иерархических определений. Мы делали аналогичное еще на P-CAD почти 20 лет назад, определяя такие блоки-макросы частоиспользуемых сценариев.


X>>>и пр., т.е. всему тому что составляет разработку современного ПО "в большом".
V>>Современый мейнстрим — это императив и ничего кроме имератива. Остальное существует постольку-постольку.

X>Да ну. JavaBeans — классический компонентный подход.

Как это противоречит императивности Джавы?

X>Stateless servlets — классическая функциональщина, хоть и записываемая в императивном стиле

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


V>>Схемы подразделяют на семь типов: структурные, функциональные, принципиальные, соединений (монтажные), подключений (схемы внешних соединений), общие и расположения
V>>и ты это как-то сдавал... Экзамен же не покупал, надеюсь?

X>Я этого не учил Непрофильное образование 0101 — Мат.Анализ.

Графы учили обязательно.


X>>>И, значит, традиционный подход будет привычен как минимум 2 будущим поколениям разработчиков.
V>>Ерунда. Современный программист не видит своей работы без элементов графического представления, таких как:
V>>- иерархия проекта (пакетов/неймспейсов)
V>>- иерархия классов
V>>- статистика вызовов и использований
V>>- диаграммы вызовов (графы) профайлеров
V>>- графы веток систем контроля версий
V>>- и т.д. до бесконечности.

X>МОЛОДЕЦ!
X>Все твои примеры — это СЛЕДСТВИЕ кода (т.е. взгляд на код под разными углами), но ни как не его ПРИЧИНА.

Мде? А я думал, что код — это следствие того, как человек себе представляет решение проблемы. Т.е. мне казалось, что иерархия классов и пакетов не "получается сама собой из кода", а именно человек так иерархически разбивает решаемую задачу, что она превращается в итоге в графы, описывающие иерархию и связи своих составных частей.

Просто некий реверс-инженерный тул, типа вашего Решарпера, генерирует эти графы исключительно как СЛЕДСТВИЕ имеющегося кода, это дааа... сие неоспоримо. ))


X>Я очень даже поддерживаю различные диаграммы и графики. Но, посмотрев на них и сделав выводы, возвращаюсь к ТЕКСТУ для изменения.

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


X>>>4) Традиционный подход доказал свою состоятельность.
V>>Традиционный подход — это графика и текст совместно в любой документации:
V>>Не понимаю, почему у некоторых чешется обязательно противопоставлять одно другому. Графические среды — это лишь попытка заполнить пропасть м/у документацией и целевым продуктом. Нормальное, ИМХО, желание.

X>До тех пор пока графы и диаграммы помогают понять код — "you'r welcome"!
X>Как только пытаются в эти графы запихать ВСЮ программу,и обязать ее модифицировать тоже через графическое представление — fail.

Всю не надо, например, "атомарно"-вычисляемую формулу зачем пихать в граф, то бишь разбивать на мн-во узлов? Пусть и будет одним узлом. Или некую неразрывную последовательность действий тоже на некоем уровне необязательно разрывать, пусть будет одним узлом — "операцией".

И что такое "графика" по-твоему? Это не только значки, это обязательно значащий текст (см любые схемы любых реальных проектов). Просто этот текст снабжен позиционированием, цветовым и блочным выделением, а лишь затем — графическими аннотациями, в т.ч. линиями (например tree-view)

Просто по сегодняшнему состоянию дел, графическое представление удобнее редактировать в тексте, но просматривать заетм таки в графике. Даже взять процесс банальной набивки HTML — 90% работы идет в исходнике, но 99% ревью — в результирующей графике.

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

Даже форматирование и отступы в исходниках — это натуральная графика для бедных. ))
Но эту графику уже давно делают графикой "для богатых": из блоков кода делают натуральный tree-view, который можно сворачивать/разворачивать, выделяют блоки текста цветом и т.д.

=====
Ну и ваши ГУИ-дизайнеры тоже не зря хлеб едят. Выделение кода не в виде строк, а в виде многогранной фигуры, где заливка и границы отличаются цветом (например, выделение текста в dotPeek) — это отличное графическое подспорье. А всего-навсего кусок текста превратили в натуральную графическую фигуру.

Здравствуйте, xvost, Вы писали:

X>Структурная декомпозиция — вещь, известная примерно 50 лет. Это был прорыв в разработке ПО тех лет.

Ничего новее в плане декомпозиций не придумали.

X>Однако индустрия не стоит на месте. И экспериментально давно доказано, что структурная декомпозиция работает хорошо ТОЛЬКО на микро-уровне, т.е. в пределах одного алгоритма или связки 2-3 алгоритмов.
X>А дальше — ООП, аспекты, компоненты, мета-... и прочее.

Вот это:

компоненты, мета-

Это и был результат "прорыва" еще 50 лет назад.
Про микро-уровень ты придумал. Структурная декомпозиция работает на любом уровне. Курить модульность.


А вот это:

ООП, аспекты

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

X>Ничего нового

Согласен. Вас надули.
Надули с "новизной" ООП и прочих ископаемых аспектов.

Здравствуйте, elmal, Вы писали:

V>>Потому что UML — это НЕ язык программирования. Это язык абстракций. На нем не напишешь полноценную программу. А на Драконе — напишешь.
E>Как это не напишешь? Ты Rational Rose видел? Тоже самое, рисуем диаграмки, внутри квадратиков набираем код (тоже скрытый), нажимаем generate — и вуаля, если все правильно то, что нагенерил, даже скомпилится. У меня в студенческие годы получалось.

Видел, делал, получалось неплохо только для объявления иерархий классов, т.е. для статики. Полноценный код так никто и не научился генерить. Искать ошибки в самом коде ДО генерения — тоже. Потому что UML не умеет. Есть несколько ОЧЕНЬ узких сценариев, где, например, по state chart что-то генерят... Но с таким колв-ом предопределенных соглашений, что похуже даже, чем в бизоне.

Ну и ты ерунду смотрел какую-то, дальше всех продвинулся в этом деле PD (Power Designer). Даже такая "мелочь" как обявление своих/произвольных паттернов в PD vs исопльзование встроенных в Розе, делает последнюю унылым Г. Роза хороша была лишь как подсказка к этапам RUP. Ну и Clear Case у них весчь, это да... А как генератор из UML в код — редкостный отстой. Малоизвестный Together на порядок мощнее был... Если бы он так безбожно не тормозил (что практически невозможно работать уже на проектах средней величины), то он мог бы стать популярным... а так не стал...


E>Дракон — крайне похожая концепция, только диаграмки другие.

Они богаче и полностью покрывают императивное программирование. Такие, казалось бы, мелочи. Отсутствующие в UML.


E>А если брать LabView — там даже генерить ничего не надо, там с помощью квадратиков можно написать полноценную программу.

Ну дык, смотря какую программу. Просто уже есть относительно много квадратиков-заготовок. Но ты можешь определять свои, аналогичные. ИМХО, это главное. Просто LabView не столько для программирования писался, сколько для макетирования. Ты можешь прогнать этот "код" в квадратиках и натравить кучу инструментов анализа на результаты. Начиная от любого сигнального анализа до статистики и даже ИИ.


E>И там тоже есть средства декомпозиции, если что.

А в графике без декомпозиции вообще никак. Иначе это будет каша.


E>Да, кстати — очень бы хотелось увидеть пример реализации быстрой сортировки на Драконе. Крайне хочется оценить понятность.

Императивная быстрая сортировка нетривиальная, в отличие от однострочных примеров на ML. Зато действительно быстрая. ))
Почему бы тебе не скачать среду и не построить эту блок-схему самому, в кач-ве небольшой разминки?

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

Здравствуйте, WolfHound, Вы писали:

WH>Datalog, SQL, EBNF,... и много что еще на дракон не ложатся. Совсем.

Блин, ну ты даааал...

Как это SQL не ложится, если есть мильон существующих тулзов графического редактирования SQL?

Далее.
EBNF имеет графического близнеца — т.н. синтаксические диаграммы.

Например, IBM, вроде бы известная тебе контора, НЕ использует BNF/EBNF в своей документации, а использует графический аналог EBNF:
http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.gsg.doc/gsg15.htm
Похоже, ты ни разу в жизни не читал их документаций...

Пример синтаксической диаграммы:


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

Здравствуйте, WolfHound, Вы писали:

WH>Что делает дракон применимым только в очень ограниченном классе задач, которые решаются конечными автоматами.

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

Здравствуйте, Cyberax, Вы писали:

C>"Передача дискеты в отдел программистов". Мда. Я бы постеснялся такие слайды показывать вообще (кроме как при обсуждении истории).

А чего тут стесняться? Бывают конторы, в которых радиусы сетевых соединений ограничены специально.

Здравствуйте, _DAle_, Вы писали:

_DA>А с каких пор pushdown automaton эквивалентен машине Тьюринга?

Ровно с тех пор, с каких машина Тьюринга эквивалентна PDA при подаче на нее заведомо конечной программы.

If we allow a finite automaton access to two stacks instead of just one, we obtain a more powerful device, equivalent in power to a Turing machine.

Фактически современные архитектуры оперируют 2-мя стеками: стеком возврата и стеком данных. Просто они размещаются физически вперемешку в одной области памяти. И дракон так же описывает вызов подпрограмм с параметрами. Выделенное курсивом оно и есть — машина Тьюринга.

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

Здравствуйте, vdimas, Вы писали:

V>Пример синтаксической диаграммы:
А можно то же самое в виде нормального EBNF?

V>Ну и я уже давным давно предлагал тебе скачать хотя бы два-три десятка тулзов для разработки компиляторов... просто посмотреть, где сейчас народ находится, а то вы малость застряли на сравнении с бизоном из 80-х... Во многих тулзах идет такое же или похожее редактирование синтаксических диаграмм.
Можно эти "многие тулзы"?

Здравствуйте, vdimas, Вы писали:

C>>"Передача дискеты в отдел программистов". Мда. Я бы постеснялся такие слайды показывать вообще (кроме как при обсуждении истории).
V>А чего тут стесняться? Бывают конторы, в которых радиусы сетевых соединений ограничены специально.
Я про всю методологию разработки.

Здравствуйте, Cyberax, Вы писали:

C>Я про всю методологию разработки.

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

Здравствуйте, Cyberax, Вы писали:

C>Я про всю методологию разработки.

А вообще, использование формального языка для постановки задачи — это на самом деле 5 баллов! Вы просто малость не в ту сторону смотрите и не то желаете там увидеть.

Здравствуйте, Cyberax, Вы писали:

C>А так вижу, что этот ДРАКОН используется очередными псевдоакадемическими бездарями чтобы мучать студентов.

Почему мучать? Свою первую более-менее сложную программу я расписал на 3-х листах в блок-схемах когда-то. И она сразу заработала. Просто у меня не было достаточно машинного времени на тот момент, чтобы позволить себе ее отладку часами... Я ее просто набил, исправил ошибки набора и она сразу заработала. А опыту было — 2 простых программы до этого (9-й класс, компы только несколько дней как в глаза увидел). В течении одного 45-минутного урока как раз успел набить программу по блок-схеме и поиграть в игру с друзьями. (это была игра Питон, которую случайно увидел на EC-терминале на экскурсии и захотелось в нее поиграть). Учитель информатики как увидел такой фокус... в общем, с тех пор у меня было неограниченное машинное время... ))

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

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП> ЧЕТЫРЕ ВИДЕОУРОКА НА YOUTUBE
ВП>по 15 минут каждый

Посмотрел 10 минут ролика. В чем отличие этой программы от LabView?

> ВП>2. Вы привели привер ПЛОХОЙ графики.
> ВП>3. Дракон-схема — это ХОРОШАЯ графика.
> В 101 раз просим привести пример реального кода на ДРАКОНе.
>
> Хотя бы в виде аналога десяти тысяч строк обычного кода. Это несколько месяцев работы обычного программиста на типичном коде.
>
> А так вижу, что этот ДРАКОН используется очередными псевдоакадемическими бездарями чтобы мучать студентов.

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

Здравствуйте, vdimas, Вы писали:

E>>Дракон — крайне похожая концепция, только диаграмки другие.
V>Они богаче и полностью покрывают императивное программирование. Такие, казалось бы, мелочи. Отсутствующие в UML.
Одно только но. Современное программирование давно не императивно. Оно является комбинацией ООП, функционального подхода, АОП, императивного, а также метапрограммирования.

V>А в графике без декомпозиции вообще никак. Иначе это будет каша.
Не в графике тоже без декомпозиции никак. Однако практика показывает, что даже в графике на декомпозицию часто забивают, предпочитая сделать ASAP, но жить с кашей. Кроме всего прочего — при реальном жизненном цикле программ постоянно требуется вносить изменения, доработки, которые не запланированы изначально и на которые не закладывались — и здесь тоже при типичной квалификации программистов получается каша, ибо быстро рефакторить мало кто умеет. Рефакторить на графических языках сложнее на порядок!

V>Императивная быстрая сортировка нетривиальная, в отличие от однострочных примеров на ML. Зато действительно быстрая. ))
V>Почему бы тебе не скачать среду и не построить эту блок-схему самому, в кач-ве небольшой разминки?
Даже нашел реализацию сам:
http://upload.wikimedia.org/wikipedia/commons/f/fd/Quicksort_in_DRAKON-Python.png
Куча состояний, внимание расфокусировано, рекурсию хрен заметишь.
Лично я никакого ускорения понимания не заметил. По сравнению с нормальной реализацией:
Псевдокод:

  function quicksort('array')
      if length('array') ≤ 1
          return 'array'  // an array of zero or one elements is already sorted
      select and remove a pivot value 'pivot' from 'array'
      create empty lists 'less' and 'greater'
      for each 'x' in 'array'
          if 'x' ≤ 'pivot' then append 'x' to 'less'
          else append 'x' to 'greater'
      return concatenate(quicksort('less'), 'pivot', quicksort('greater')) // two recursive calls

Реализация:

def quicksort(list, p, r)
    if p < r then
        q = partition(list, p, r)
        quicksort(list, p, q-1)
        quicksort(list, q+1, r)
    end
end
 
def partition(list, p, r)
    pivot = list[r]
    i = p - 1
    p.upto(r-1) do |j|
        if list[j] <= pivot
            i = i+1
            list[i], list[j] = list[j],list[i]
        end       
    end
    list[i+1],list[r] = list[r],list[i+1]
    return i + 1
end

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

Здравствуйте, elmal, Вы писали:

E>Даже нашел реализацию сам:
E>http://upload.wikimedia.org/wikipedia/commons/f/fd/Quicksort_in_DRAKON-Python.png
E>Куча состояний, внимание расфокусировано, рекурсию хрен заметишь.
Она еще и не по месту сортирует

Здравствуйте, elmal, Вы писали:

E>Лично для меня псевдокод и реализация читается и понимается на порядок легче.

Ничего для тебя не понимается вообще, в графике и в псевдокоде приведены разные реализации.


E>Я не одинок — LapteVV подтвердил, что подавляющее большинство студентов блок схемы воспринимают значительно хуже, чем запись алгоритма по шагам.

В твоем случае, хуже в бесконечное кол-во раз, бо деление на 0 дает бесконечность. Заплутать в 3-х соснах, это пять. ))


E>Те, кто блок схемы понимают лучше — те разработчиками не становятся обычно, они идут в тестеры, аналитики, менеджеры, HRы или вообще в домохозяйки.

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

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

Здравствуйте, vdimas, Вы писали:

C>>Я про всю методологию разработки.
V>Ну дык аналитеги рисуют постановку, требования и прочие умыльные юз-кейзы и передают разработчикам на условных дискетах... Та же фигня, вид в профиль. Слухи об устаревании подобной методологии, поверь, крайне преждевременны. От артефактов внутренней документации программисты не избавятся никогда, как бы им порой не хотелось обратного.
Дело в том, что ДРАКОН — это не язык разработки use-case'ов и для описания формальных требований он тоже не очень подходит.

Получается непонятная шизофрения — с одной стороны инжинеры должны описывать алгоритм на некотором почти-формальном языке, а с другой стороны программисты должны по этому намалёванному непотребию потом делать что-то работающее. Я прямо отсюда слышу их матюки.

Т.е. я совсем не против методологии, где инжинеры описывают формальные требования, по которым потом создаётся код. Но для этого надо иметь соответствующие инструменты. И самый главный из них — старый добрый текст. Диаграммы имеют смысл, но только для:
1) Иллюстрации общей структуры (т.е. иерархические диаграммы).
2) Диаграммы для КА (в различных формах).