Наглядность схем для алгоритмов.

[valexey]

Вот тут предлагают оценить наглядность классической реализации втавки в avl-дереве (видимо на паскале) и "реализации" её же в виде схемы на драконе. Утверждается что драконовской схемой нагляднее получается.

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

[vlad]

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

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

[valexey]

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

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

[Valery Solovey]

Схема должна вся умещаться в поле зрения. Поэтому, схему нужно распечатать на подходящем формате.

[Valery Solovey]

как я понимаю, средств декомпозиции вменяемых у Дракона нет

Аналог процедур есть.

[valexey]

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

[valexey]

как я понимаю, средств декомпозиции вменяемых у Дракона нет

Аналог процедур есть.

Можно пример?

[vlad]

Если этот "мусор" убрать, то от алгоритма в общем то ничего и не останется :-)

Останется. Там много непонятных ветвлений, которые на нормальной схеме можно обозначить чем-то более вменяемым, чем 1, 0, -1.

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

В паскале очень трудно убрать мусор Это ж даже не питон

[valexey]

Схема должна вся умещаться в поле зрения. Поэтому, схему нужно распечатать на подходящем формате.

Эмм. А как её собственно редактировать потом? Вот я работаю на ноуте c экраном 13". Код пишу в том числе. Я слабо представляю как вот в подобном "коде" мне разбираться и править его.

Предлагается возродить кульман на рабочем месте? :-)

[valexey]

Если этот "мусор" убрать, то от алгоритма в общем то ничего и не останется :-)

Останется. Там много непонятных ветвлений, которые на нормальной схеме можно обозначить чем-то более вменяемым, чем 1, 0, -1.

Откровенно говоря, в нормальном коде тоже должно быть что-то более вменяемое чем вот эти вот магические числа :-)

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

В паскале очень трудно убрать мусор Это ж даже не питон

Но для данного класса алгоритмов вполне возможно. Впрочем, конечно на С++ мусор убирается сильно проще.

[vlad]

Откровенно говоря, в нормальном коде тоже должно быть что-то более вменяемое чем вот эти вот магические числа :-)

Все равно. Ветвления/состояния на драконовских схемах выглядят лучше.

[valexey]

Откровенно говоря, в нормальном коде тоже должно быть что-то более вменяемое чем вот эти вот магические числа :-)

Все равно. Ветвления/состояния на драконовских схемах выглядят лучше.

Состояния и переходы много лучше выглядят на схеме конечного автомата. А это ни разу не дракон.

[Valery Solovey]

Можно пример?

С примером затрудняюсь. Помню, как-то пару лет назад обсуждалась данная тема на форуме. Предлагалось то ли "примитив" для этого использовать, то ли ещё что-то. Но я не помню, в классической версии языка (от Паронджанова) так предлагалось делать или в обновлённой, которую пытались всем скопом на форуме сделать.

[Valery Solovey]

Если я тогда правильно уловил мысль, то работать оно должно было так:
1. Составляется "примитив".
2. В основной схеме упоминается примитив, что является аналогом вызова с возвратом.

[vlad]

Все равно. Ветвления/состояния на драконовских схемах выглядят лучше.

Состояния и переходы много лучше выглядят на схеме конечного автомата. А это ни разу не дракон.

Какое именно представление ты понимаешь под "схемой конечного автомата". КА можно и в табличной форме выразить. Только это будет ни разу не нагляднее дракона.