[image]

язык ДРАКОН

неожиданно
Теги:космос
 
RU кщееш #06.08.2019 20:11
+
+1
-
edit
 

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

Ежегодно тысячи будущих врачей в Литве получают образование при помощи инновационной гибридной методики, которая совмещает дистанционное обучение с отработкой практических навыков в симуляционном классе. В отличие от обычных медицинских курсов, тут нет преподавателя или инструктора: его заменяет алгоритм, написанный на визуальном языке программирования ДРАКОН - простом, понятном и исключающем возможность врачебной ошибки. Однако ДРАКОН - вовсе не собственная разработка литовских медиков, а побочный продукт советской космической программы "Энергия - Буран", закрытой в начале 90-х. Два десятилетия спустя язык фактически обрел в Литве новую жизнь - совершенно в другом качестве. //  www.bbc.com
 
   76.0.3809.8776.0.3809.87
RU Zenitchik #07.08.2019 13:55  @кщееш#06.08.2019 20:11
+
-
edit
 

Zenitchik

втянувшийся

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

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

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

у меня такое впечатление от всех без исключения языков начиная с фортрана)))))
   76.0.3809.8776.0.3809.87
RU Zenitchik #07.08.2019 14:09  @кщееш#07.08.2019 14:05
+
-
edit
 

Zenitchik

втянувшийся

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

А заканчивая чем?
   75.0.3770.14575.0.3770.145
RU кщееш #07.08.2019 14:28  @Zenitchik#07.08.2019 14:09
+
-
edit
 
кщееш>> у меня такое впечатление от всех без исключения языков начиная с фортрана)))))
Zenitchik> А заканчивая чем?

китайским))))
   76.0.3809.8776.0.3809.87
DE TEvg-2 #07.08.2019 20:50  @кщееш#06.08.2019 20:11
+
-
edit
 
DE TEvg-2 #07.08.2019 20:55  @кщееш#07.08.2019 14:05
+
-
edit
 

TEvg-2

мракобес

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

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

Oleg_NZH

втянувшийся

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

Это всем давно известно . Вольность , расхлябанность , "чё хочу - то и ворочу " , а я - художник- я так видЮ..И т.д.(Холивар между Си и Паскалем - бесконечен) Когда ограничиваются Рамки дозволенного - то это благоприятно сказывается на процесс формулировки Задачи , и Её Реализации . Вместо того , что-бы придумывать - как там Медведи на Балалайке будут играть при визуализации - Нужно в первую очередь задумываться о Сути Вопроса . НО! Существуют алгоритмы и всякая скучная , "не красивая" ..." чо вы мне тут втираете заумности" (с точки зрения Заказчика) дребедень . :(
   68.068.0
RU кщееш #08.08.2019 09:39  @TEvg-2#07.08.2019 20:50
+
-
edit
 
кщееш>> Космический ДРАКОН. Как заброшенный проект "Роскосмоса" подарил язык литовской медицине - BBC News Русская служба
TEvg-2> По моему мы это изучали в школе под названием алгоритмический язык.

Вот лучше бы ему и учили только. Имхо
   71.0.3578.14171.0.3578.141
+
+1
-
edit
 

U235

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

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

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

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

U235

старожил
★★★★★
кщееш> Вот лучше бы ему и учили только. Имхо

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

Oleg_NZH

втянувшийся

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

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

Xan

координатор

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

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

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

Дракон им сильно помог бы, на мой взгляд.
   66
RU Zenitchik #08.08.2019 15:15
+
+1
-
edit
 

Zenitchik

втянувшийся

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

Вообще, ДРАКОН-1 как стандарт блок-схем мне понравился, простые куски алгоритмов удобно рисовать на нём, но, увы, на бумаге. От идеи работать, постоянно хватаясь то за мышь то за клавиатуру - меня лично коробит.
Возможно, был бы интересен какой-нибудь "Драконоид" для мобильных устройств.
   75.0.3770.14575.0.3770.145

U235

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

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

Xan

координатор

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

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

TEvg-2

мракобес

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

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

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

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

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

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

Oleg_NZH

втянувшийся

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

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

Zenitchik

втянувшийся

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

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

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

Ну, как Вам сказать... Во встраиваемых приложениях, конечно, есть свои ограничения. Но на ПК - скорее всего компилятор оптимизирует всю эту бороду вызовов лучше, чем человек. Поэтому дробление процедур - чисто по соображениям абстрагирования и повторного использования кода.
   75.0.3770.14575.0.3770.145
RU Oleg_NZH #08.08.2019 20:58  @Zenitchik#08.08.2019 20:08
+
-
edit
 

Oleg_NZH

втянувшийся

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

Есть , например , такая штуковина - как inline . Компилятор , со своим ИИ столько может начудить . Код или в плюс или в минус по размеру сообразит . (Это про стек в том числе - нужно-ли вызывать функцию , предварительно сохраняя в стеке всё барахло , и потом вытаскивать обратно...)
   68.068.0
RU Zenitchik #08.08.2019 22:19  @Oleg_NZH#08.08.2019 20:58
+
-
edit
 

Zenitchik

втянувшийся

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

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

U235

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

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

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

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

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

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

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

Oleg_NZH

втянувшийся

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


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

PSS

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

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

Вариант представления ТЗ, грубо говоря
   66
AD Реклама Google — средство выживания форумов :)
RU spam_test #09.08.2019 08:39  @Oleg_NZH#09.08.2019 08:26
+
-
edit
 

spam_test

аксакал

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

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru