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

>>Это и не нужно. Достаточно лишь сформулировать то, что нужно от программы/функции. Блок схема - это разработка от малого к большому, изнутри снаружу. Разве это хорошо?

что за бред? сначала строишь обобщенный алгоритм. потом каждый блок можно специализировать более детальной блок-схемой.

> делаешь ты экономический калькулятор, а заказчик попросил asap приделать к нему возможность смотреть всё через сайт. Назавтра ты сделал сайт, заказчик подумал и решил что калькулятор вообще не нужен. Может статься так, что сейчас сущности связаны, а через час они развяжутся и станут вообще чем-то прямо противоположным.

Да ты где-то начитался маркетингового пиара про гибкие методологии :D При сильноменяющихся требованиях код очень быстро скатывается в неразгребаемое говно; кто-то из сторонников XP рассказывал про метод «положиться в банк» у денежной купюры. В какой-то момент становится проще переписать треть программы с нуля, чем продолжать попытки ее рефакторинга — и тут нужно будет рисовать квадратики, чтобы новый код не оказался того же качества, что и старый. Кроме того, квадратики полезны при планировании каждой итерации, когда принимаются решения, как именно реализовывать очередную порцию хотелок заказчика.

Но принцип иллюстрирует. А иллюстрации противоположного пока не видно.

При сильноменяющихся требованиях код очень быстро скатывается в неразгребаемое говно

а я и не утверждал обратного. Другое дело что пока заказчик платит бабло, считая что описанная тобой модель развития событий для него вполне подходит, можно тянуть на этом довольно долго. Причем даже дольше, чем живут проги разработанные на основе «правильной» архитектуры. Что сдохнет-то понятно, но если заказчик используя прогу успеет ее окупить до того как она загнется, то овчинка вполне стоила выделки.

ужас какой!! ><
*ушел читать книжку по Common Lisp

Посмотри на .NET WWF

>>Бытует мнение, что на типичной диаграмме должно быть не больше 5-10 квадратиков. Никаких «огромных простыней».

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

Вот только среднее человеческое сознание произвольно оперирует 7±2 объектами без всяких схем. Так что схемы нужны только если что-то имеет значительно бОльшую сложность.

> Блоксхемы в программировании — всего лишь ужасная вещь в учебном процессе студентов. Более они ни для чего при разработке ПО не нужны.
Но ДРАКОН — это же не блок-схемы.

> да, я знаю, что практически все студенты этим и занимаются, когда делают свои курсовые под конец семестра, - быстро-быстро каждый оператор представляют соответствующим элементом для БС, - но БС уже не нужна, если программа написана =))
Скажи это преподам. *вспоминает, как он делал блок-схему на целый лист, когда сама программа для курсовой занимала всего треть страницы... у других студентов, правда, и программа и схема для этой задачи занимали почему-то по десятку страниц*

На счёт программирования, блок-схем и наглядности. Есть такой проект Scratch, призванный заменить для школьников Логомиры.

>Блоксхемы отличная вещь. Еслиб разработка программ начиналась с них, былоб меньше багов.

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

Ты осиль К&R __прочитать__ для начала, а потом уже будешь заикаться про «выучить».

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

Но блок-схемы таки всё равно прошлый век. UML, IDEF0, IDEF1x наше всё.

> Вот только среднее человеческое сознание произвольно оперирует 7±2 объектами без всяких схем. Так что схемы нужны только если что-то имеет значительно бОльшую сложность.

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

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

Так я ещё раз повторю, что тем, что у тебя укладывается в голове, ты можешь оперировать и без графической визуализации :D

От простыни из переплетенных стрелками сотен квадратиков толку очень мало.

На электронных схемах толку от этого очень много :D http://www.tis.kz/progs/agat/0001/sysboard-elect-0-p1-h.jpg

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

1.Remove the brain
2.Place brain into transport container
3.Prepare ALL documents
4.Send the brain by plane to Moscow
5.Wait until DRAKON Programming Guide is copied to your brain.

Пункт 5 придумал я, остальное - из демонстрационной блок-схемы.

Ссылка доставила.

>Ссылка доставила.

А теперь прикинь, когда такую схему сам разрабатываешь. Придумывая из головы и рисуя на листах тетрадной бумаги... :D Ну, точнее, попроще обычно что-то выдумывалось, но с десяток корпусов, сколько-то дискретки и многие сотни связей - это вполне нормальный уровень для пары вечеров работы :)

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

> ни они последние терпят на этом пути фиаско.

BPMN вполне себе цветёт и пахнет в своей области. Хотя поддержки больших компаний сильно не хватает

Иногда листинги пишутся ручкой на бумажке. Несмотря на то, что «в процессе написания алгоритм меняется, и не раз». Поэтому не аргумент.

Пример в статье просто шикарный.

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

А у вас наоборот

Что у меня «наоборот»?

Как вообще ваш коммент связан с тем, на который вы отвечаете? Вы не согласны, что произвольный уровень абстракции/детализации может быть выражен средствами ЯП? Или что?

Хотел сказать, что БС используют не для абстракции, а скорее для наглядности и универсальности. Пропустил последнее предложение вашего комента поэтому неправильно понял, извиняюсь.-)

З.Ы. Кстати в своем неудачном посте процитировал ГОСТ