язык ДРАКОН

кщееш> Космический ДРАКОН. Как заброшенный проект "Роскосмоса" подарил язык литовской медицине - BBC News Русская служба

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

Дочитаю книжку по этому самому Дракону - скажу что с ним как. Но первое впечатление: язык довольно корявый.

кщееш>> Космический ДРАКОН. Как заброшенный проект "Роскосмоса" подарил язык литовской медицине - BBC News Русская служба
Zenitchik> Тут можно долго спорить графические vs обычные языки программирования.
Zenitchik> Практика показывает, что хорошие графические решения получаются для доменно-специфических языков, для универсальных - что-то не то.
Zenitchik> Есть общее соображение: большинству людей всё-таки писать легче, чем рисовать. Поэтому язык, похожий на текст, оказывается удобнее для использования, чем язык, похожий на картинку.
Zenitchik> Дочитаю книжку по этому самому Дракону - скажу что с ним как. Но первое впечатление: язык довольно корявый.

у меня такое впечатление от всех без исключения языков начиная с фортрана)))))

кщееш> у меня такое впечатление от всех без исключения языков начиная с фортрана)))))

А заканчивая чем?

кщееш>> у меня такое впечатление от всех без исключения языков начиная с фортрана)))))
Zenitchik> А заканчивая чем?

китайским))))

кщееш> Космический ДРАКОН. Как заброшенный проект "Роскосмоса" подарил язык литовской медицине - BBC News Русская служба

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

Zenitchik>> Дочитаю книжку по этому самому Дракону - скажу что с ним как. Но первое впечатление: язык довольно корявый.
кщееш> у меня такое впечатление от всех без исключения языков начиная с фортрана)))))

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

кщееш>> у меня такое впечатление от всех без исключения языков начиная с фортрана)))))
TEvg-2> Самое паршивое что их плодят в диких количествах. А результат либо посредственный, либо ужасный. Плюс куча диалектов, плюс куча фреймворков. Вместо облегчения жизни, получается совсем обратный результат.

Это всем давно известно . Вольность , расхлябанность , "чё хочу - то и ворочу " , а я - художник- я так видЮ..И т.д.(Холивар между Си и Паскалем - бесконечен) Когда ограничиваются Рамки дозволенного - то это благоприятно сказывается на процесс формулировки Задачи , и Её Реализации . Вместо того , что-бы придумывать - как там Медведи на Балалайке будут играть при визуализации - Нужно в первую очередь задумываться о Сути Вопроса . НО! Существуют алгоритмы и всякая скучная , "не красивая" ..." чо вы мне тут втираете заумности" (с точки зрения Заказчика) дребедень .

кщееш>> Космический ДРАКОН. Как заброшенный проект "Роскосмоса" подарил язык литовской медицине - BBC News Русская служба
TEvg-2> По моему мы это изучали в школе под названием алгоритмический язык.

Вот лучше бы ему и учили только. Имхо

O.N.> Это всем давно известно . Вольность , расхлябанность , "чё хочу - то и ворочу " , а я - художник- я так видЮ..И т.д.(Холивар между Си и Паскалем - бесконечен)

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

O.N.> Когда ограничиваются Рамки дозволенного - то это благоприятно сказывается на процесс формулировки Задачи

Но крайне хреново сказывается на читабельности кода, его размере, скорости разработки. Было бы все так кучеряво, писали бы на ассемблере и не парились. Но масштабные проекты запаришься на ассемблере писать. для упрощения и ускорения разработки придумали сначала процедурные языки, а потом - и объектно-ориентированные, плюс постоянно еще какие-то новые подходы пытаются выдумать, но старый добрый ООП пока что рулит.

кщееш> Вот лучше бы ему и учили только. Имхо

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

U235> Но крайне хреново сказывается на читабельности кода, его размере, скорости разработки. Было бы все так кучеряво, писали бы на ассемблере и не парились. Но масштабные проекты запаришься на ассемблере писать. для упрощения и ускорения разработки придумали сначала процедурные языки, а потом - и объектно-ориентированные, плюс постоянно еще какие-то новые подходы пытаются выдумать, но старый добрый ООП пока что рулит.

Да это бесконечная История. Я вот на ANSI C пишу(ASSM - уже лет 20 не пользую, только вставками) .А ООП даже в STM-ки толком не "влазит". Не - простор для Творчества и безалаберности - огромный . В том-же Modbus - как хочешь интерпретируй данные - просто набор байтов-битов. Да и в Паскале - Variant - очумелаявшая штуковина .

U235> или напишет такое, что увидевшим это оно потом в страшном сне сниться будет.

Я видел код индийских погромистов!
И остался жив!
Но было страшно!!!

Они самоучки, понахватавшиеся случайных знаний. Которым не вдолбили основы.
Вот боинги и падают.

Дракон им сильно помог бы, на мой взгляд.

Xan> Дракон им сильно помог бы, на мой взгляд.

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

Xan>> Дракон им сильно помог бы, на мой взгляд.
U235> Ну как им этот набор правил рисования блок-схем поможет

То, что я видел, было настолько ужасным... !!!

U235>Что глобальные переменные - это плохая идея и по возможности надо держаться от них подальше?

Это хорошая идея. Как и GOTO / JMP
Просто надо уметь ими пользоваться.

>Что одна процедура - одно действие.

Процедура - это call + ret, плюс дергание стека. Поэтому не нужно увлекаться дроблением процедур.

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

С этим можно согласиться.

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

И тут Мгновенно возникает паскудный Вопрос , Жестокий!... Прерывания. Вот где сломано куча копий . (особенно у "железячников")

U235>>Что глобальные переменные - это плохая идея и по возможности надо держаться от них подальше?
TEvg-2> Это хорошая идея. Как и GOTO / JMP
TEvg-2> Просто надо уметь ими пользоваться.

Случаи, когда это хорошая идея - можно пересчитать по пальцам одной руки, причём, типичному программисту эти случаи скорее всего никогда не встретятся.
Поэтому можно слегка утрировать, что и сделал U235

>Процедура - это call + ret, плюс дергание стека. Поэтому не нужно увлекаться дроблением процедур.

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

>>Процедура - это call + ret, плюс дергание стека. Поэтому не нужно увлекаться дроблением процедур.
Zenitchik> Ну, как Вам сказать... Во встраиваемых приложениях, конечно, есть свои ограничения. Но на ПК - скорее всего компилятор оптимизирует всю эту бороду вызовов лучше, чем человек. Поэтому дробление процедур - чисто по соображениям абстрагирования и повторного использования кода.

Есть , например , такая штуковина - как inline . Компилятор , со своим ИИ столько может начудить . Код или в плюс или в минус по размеру сообразит . (Это про стек в том числе - нужно-ли вызывать функцию , предварительно сохраняя в стеке всё барахло , и потом вытаскивать обратно...)

O.N.> Есть , например , такая штуковина - как inline . Компилятор , со своим ИИ столько может начудить . Код или в плюс или в минус по размеру сообразит . (Это про стек в том числе - нужно-ли вызывать функцию , предварительно сохраняя в стеке всё барахло , и потом вытаскивать обратно...)

А ещё есть такая штуковина, как оптимизация хвостовой рекурсии.

TEvg-2> Это хорошая идея. Как и GOTO / JMP

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

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

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

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

TEvg-2> Процедура - это call + ret, плюс дергание стека. Поэтому не нужно увлекаться дроблением процедур.

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

TEvg-2> Это хорошая идея. Как и GOTO / JMP
TEvg-2> Просто надо уметь ими пользоваться.


Немножко оффтопа. (Просто ностальжи пробило)
В конце 80-х делал стенд на Apple II (Правец 8) . На Бэйсике . Сотни строк кода . А там Call и Goto на номера строк . Сначала всё нормально - автоматическая нумерация через 10 , и вставляешь нужное . Затем , когда всё хозяйство разрастается и начинаются проблемы .Renumber хоть всё и перекраивает - но забываются все эти цифири - куда и зачем goto-шничаешь. Приходилось изгаляться -Все подпрограммы объявлять в начале программы (как в Си - предварительное объявление функций (Хотя с Си тогда был не знаком- Только Фортран , и то благодаря Отцу (Он Физик))) с ремарками- что почём и зачем ...и оттуда уже делать Call и Goto по телу программы (иначе в этих номерах строк - безумное блуждание). (Мало того - там для интерпретатора - - Дикое распределение Памяти! Первые 2К под текст на Бэйсике , затем !!! - две экранные области 2x2К(вроде-бы) , затем свободная память. В эти первые 2К ничерта не влезало - благо был компилятор , который уже в верхнюю часть закидывал всё.. )
Короче -как вспомню-так вздрогну.

Xan>> Дракон им сильно помог бы, на мой взгляд.
U235> Ну как им этот набор правил рисования блок-схем поможет понять, что нельзя мешать несколько уровней абстракции в одной процедуре?

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

Вариант представления ТЗ, грубо говоря

O.N.> Короче -как вспомню-так вздрогну.
Когда учился, лицезрел учебное задание решенное на Паскале в стиле Бейсика (т.к. автор его хорошо знал и изучал в школе). Это был Ԥ