L>Смею предположить, что люди, которые предпочитают работать с картинкой, дружно идут лесом, когда надо сделать мало-мальски сложную программу.
Нет. Системы управления с микропроцессорами — я лично общался с людьми, которые делают достаточно сложные системы, и они не программисты.
Посмотрите в моем видеодокладе.
Я знаком с Паронджановым лично, и он рассказывал, что при разработке системы управления Бурана
сначала ИНЖЕНЕРЫ чертили схемы управления (была разработана некая технология — предшественник дракона)
а потом программисты по схеме однозначно переводили это в программы для ботового компьютера.
Согласитесь, что та разработка была феноменально успешна:
на компьютерах с килобайтами памяти безошибочно сработала система автоматического управления.
И посадила Буран в сложных погодных условиях (был косой боковой ветер, который сносил планер).
Система приняла решение сделать разворот над полосой и сесть с противоположной стороны.
Та система почти не требовала отладки, так как кодировались уже правильные алгоритмы.
Нарисованные как формализованные схемы.

AN>Т.е. — сейчас нет такой практики, что набрать студентов больше, чем есть мест, а на первом курсе устроить жёсткий отсев?
Набирается больше за счет коммерческих.
Но БЫСТРОГО и ЖЕСТКОГО отсева не получается из-за условий, в которые нас ставит министерство.
Вообще по моим наблюдениям, которые подтвердил Шалыто в интервью 2017 года, заканчивает 1/4 часть от поступивших.
У нас при примерно 40 поступивших завершает обычно не более 10. В итмо — при 200 принятых — завершает примерно 50 (это озвучил Шалыто)
LVV>>Второе. К нам часто едут из Казахстана и из Африки.
LVV>>Естественно, большинство коммерческих. Им пофигу, сколько учиться.
AN>Если за каждый повторный год платит, то, конечно не выгонят
Ну, совсем уж никаких все же отчисляют, и им приходится повторно платить за тот же год. Тоже выгода.
AN>Когда я учился, тех кто отлично учился на платном, переводили на бюджетное обучение.
AN>В Астраханском ГУ это практикуется?
АГТУ. АГУ — это не мы.
Практикуется. 2 сессии без троек — и при наличии свободных мест — переводим. Сам участвую в этих заседаниях нашего ученого совета.
LVV>>Не раз было так: вылетел после 2 курса. Через год опять пришел, опять на 2 курс. И даже были случаи, когда второй раз реально брался за ум и вполне себе нормально учился.
AN>Случаи разные бывают. Были 2 однокурсника, которые решили, что не хотят ИТ заниматься. Ушли на 2-м курсе, после армии один восстановился, второй поступил в другой технический ВУЗ, причём сданные у нас экзамены и зачёты ему перезачли.
У нас перезачеты, естественно, тоже есть.
Но к нам перевестись сложно.
Из МФТИ чел с программной инженерии на нашу программную инженерию не смог перевестись из-за разницы планов.
Он в МФТИ закончил 3 курс, а к нам хотел на 4-й.
Но! мы смогли его только на 2-й.
У него там было 2 курсовых за 3 года, а у нас 2 курсовых КАЖДЫЙ семестр.
И еще учебные и производственные практики.
В общем, по нормативам министерства — никак не получалось даже на третий.
Это к вопросу о стандартах и их фактическом отсутствии...

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

L>>Сильно подозреваю, что кому-то уже пришла в голову обратная идея: писать программу как обычно, а потом на основе написанного кода автоматически генерировать блок-схему. Смею предположить, что в общем случае мало-мальски опытный программист гораздо быстрее напишет код, чем нарисует блок-схему.
LVV>Работать с текстом или картинкой — зависит от психотипа.
LVV>Программисты в огромном большинстве — да.
LVV>Но!
LVV>а) есть люди (и девочки — почти все), которые просто предпочитают картинку.

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

LVV>б) есть множество специалистов, которым алгоритмы делать надо, но они хотят их чертить, а не писать. Не программисты.

Как они потом эти аглоритмы переводят в код, который можно выполнить?

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

LVV>Та система почти не требовала отладки, так как кодировались уже правильные алгоритмы.
LVV>Нарисованные как формализованные схемы.

Кто и как правильность аглоритмов проверял?

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

LVV>Я знаком с Паронджановым лично, и он рассказывал, что при разработке системы управления Бурана
LVV>сначала ИНЖЕНЕРЫ чертили схемы управления (была разработана некая технология — предшественник дракона)
LVV>а потом программисты по схеме однозначно переводили это в программы для ботового компьютера.

Смутно подозреваю, что разработка системы управления космическим кораблем — особый случай, а в общем случае разрабатывать таким образом современные программы крайне неэффективно.

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

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

Ну будет графичекий diff.
Точно так-же на картинках ты будешь видеть красные и зелёные фрагменты.

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

A>Ну будет графичекий diff.
A>Точно так-же на картинках ты будешь видеть красные и зелёные фрагменты.

Можно привести 2-3 примера?

L>Смутно подозреваю, что разработка системы управления космическим кораблем — особый случай, а в общем случае разрабатывать таким образом современные программы крайне неэффективно.
Дело в том, что подобных систем дофига не только в околовооружениях.
Например, в стиралке микропроцессор и там система управления.
В автомобиле компьютер. Не говоря уж о специальных системах (мне в Овене показывали).
Помнится, в САРНИГМИ каждую ночь рассчитывалась погода на весь среднеазиатский регион СССР.
дык данные поступали с датчиков, которые были раскиданы по всей Средней Азии (сам видел эти шкафы)
В общем, мэйнстримная типовая обработка данных — это только одно направление разработки.

Уважаемые коллеги!

Восемь лет назад, в 2012 году, Сергей Ефанов опубликовал статью

"Программирование микроконтроллеров на ДРАКОНе".

После статьи 4 видео и 279 комментариев.
http://we.easyelectronics.ru/drakon/programmirovanie-mikrokontrollerov-na-drakone.html

В этой статье и в комментариях можно найти ответы на некоторые (конечно, не на все, а только на некоторые) вопросы и сомнения, которые здесь прозвучали.

LVV>>Та система почти не требовала отладки, так как кодировались уже правильные алгоритмы.
LVV>>Нарисованные как формализованные схемы.
AN>Кто и как правильность аглоритмов проверял?
Дык а) на земле
б) практика показала.
Единственная система, которая в автоматическом режиме смогла посадить челнок.
В сложных погодных условиях.

A>>Обрыв линии ты видишь сразу. А незакрытую скобку ещё попробуй найди.
DO>Практически любой алгоритм в виде схемы сложнее "Hello world" не влезет в экран. Как правило это будет безумный лес из спагетти линий и разных кватратиков/ромбиков/овальчиков/etc, и найти там обрыв линии не легче, чем незакрытую скобку, а то и сложнее.
В том-то и дело, что "безумного леса" не наблюдается из-зы строгих правил Дракона.
На блок-схемах — да, безумный лес.
У меня вот в курсовой один перец изобразил несколько ветвлений с уходом в левую часть (по-арабски... ),
да еще и да-нет по-разному на разных ветках.
В Драконе все жестко. И леса не получается.
бесконечные схемы (как и всю прогу в одной main()) — никтотне рисует. Рисуют либо прототип, лтибо небольшой силуэт.
Малые схемы делают макроиконами и потом эту макроикону вставляют в бОльшую схему.
Ну, как программисты и делают — только с кодом.
Я сам это видел у конкретного чела в конкретной конторе и в конкретной разработке.

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

LVV>Система приняла решение сделать разворот над полосой и сесть с противоположной стороны.
Не надо такую глупость говорить. С противоположной стороны означало сеть по ветру, что крайне большая глупость в данных метеоусловиях и скорее всего все закончилось бы фатально, полосы бы не хватило. И над полосой он не разворачивался, это тоже бы ни к чему хорошего не привело. Что было — ожидалось, что заход будет левым разворотом, все шло к этому, а он зашел правым, хотя его ветер сдул вправо. При этом это не означает, что сесть как ожидалось было бы неправильным решением, просто в алгоритме была заложена соответствующая свобода действий и алгоритм этой свободой воспользовался, посчитав, что так будет оптимальнее. На деле там не такие уж и сложные расчеты и совсем не сверхсложный алгоритм, огромного количества памяти для него явно не требовалось, да и сведхбыстродействие тоже не требовалось. Задача конечно интересная, особенно для тех лет, но все технологии для ее решения были давно в наличии с ИТшной точки зрения.

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

LVV>Работать с текстом или картинкой — зависит от психотипа.
LVV>Программисты в огромном большинстве — да.

Дело не только и не столько в психотипе. Есть две вполне объективне проблемы:
1) Чисто технически описать сложную конструкцию текстом на клавиатуре в разы, если не на порядки быстрее. А если сравнить с современными редакторами типа того что в Студии или Райдере, то разрыв становится галактическим.
2) Графические языки очень, нет, ОЧЕНЬ хреново масштабируются. Графические схемы с десятком сущностей ещ как то воспринимаются, когда счет начинает идти на сотни все становится неудобоваримым.

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

НС>И если по п.1 еще есть шанс что то исправить, хотя это и задачка крайне высокой сложности и требующая нестандартного подхода, то с п.2, боюсь, мало что можно сделать. Не зря же человечество задолго до компов стало передавать знания практически исключительно текстом.
Я во многом согласен.
Но все же...
1. Мы опрашивали студентов нескольких групп разных возрастов. Девочки предпочитают картинку (блок-схему)
Мальчики — в огромном большинстве — текст. Но есть и те (их очень мало), кому пофигу.
2. Попытки использовать графические языке не прекращаются.
Вспоминаю Р-схемы и РТК-комплекс, которые начинались в СССР : http://emag.iis.ru/arc/infosoc/emag.nsf/BPA/e72abd849fe68a7dc32576eb0034c090
И ведь система реально работала и развивалась, но с приходом Горбачева все стало загибаться.
3. Вот прямо сейчас меня по телефону домогается мужик, которому до зарезу нужна Drakon IDE — построение и отладка Дракон-схем.
Мне навязывали денежный договор на разработку очень настойчиво.
Мой доклад в Орле на эту тему на ютубе посмотрели более 1500 человек — я просто фигею! Обычная цифра — 100-200 просмотров.
Значит, кому-то это НУЖНО реально.

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

LVV>1. Мы опрашивали студентов нескольких групп разных возрастов. Девочки предпочитают картинку (блок-схему)
LVV>Мальчики — в огромном большинстве — текст. Но есть и те (их очень мало), кому пофигу.

А сколько в вашем вопросе было сущностей на картинке? Как думаешь, будет ли меняться ответ, если на ней будет 100 сущностей? 1000?

LVV>2. Попытки использовать графические языке не прекращаются.

И в случае программирования все попытки строго неудачные.

LVV>3. Вот прямо сейчас меня по телефону домогается мужик, которому до зарезу нужна Drakon IDE — построение и отладка Дракон-схем.
LVV>Мне навязывали денежный договор на разработку очень настойчиво.

Фриков много, в том числе и таких кто хочет потратить деньги, особенно если деньги не свои.

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

LVV>В том-то и дело, что "безумного леса" не наблюдается из-зы строгих правил Дракона.
Именно из-за строгих правил у Дракона нет и не будет большого будущего в массовой коммерческой разработке. Строго нишевый продукт.

LVV>В Драконе все жестко. И леса не получается.
LVV>бесконечные схемы (как и всю прогу в одной main()) — никтотне рисует. Рисуют либо прототип, лтибо небольшой силуэт.
LVV>Малые схемы делают макроиконами и потом эту макроикону вставляют в бОльшую схему.
Чтобы посмотреть вложенную схему нужно провалиться в иконку? А если таких вложений много? В какой-то момент надоест тыкаться и перейдешь на текст.

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

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

MH>>Понятно что графическое представление алгоритмов в некоторых случаях и для некоторых удобнее
LK>По-моему, вся эта графика куда менее удобна, чем табулированный и комментированный текстовый код. Хотя бы за счёт меньшей плотности: приходится бегать глазами по диаграмме, которая может быть не маленькой.
LK>Кроме того, непонятно: если человек запомнил графический "условный ромб", почему он не в силах запомнить директивы "if-then-else"? В чём тут принципиальное отличие?

+1, однако я нашел случай удачного применения графических схем, когда ребенок стал изучать scratch
Он графический и с ним можно быстро создать программу и даже вполне рабочую игру.

Суть в том, что ребенок еще пока очень, очень медленно печатает. С текстом он бы просто сломался сразу и никуда не продвинулся в изучении. А тут перетаскивая мышкой блоки и вбивая только параметры — вполне успешно собирает программу и учится.

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

ВП>

Я на ДРАКОНе работаю уже 6 лет.
ВП>Любое создание программы начинаю с него и при отладке работаю только с ним.

ВП>Скорость разработки, качество возрастает в разы!
ВП>ДРАКОН это сила, но многие не догоняют, думают, что это обычная блок-схема...

НИЧЕГО НЕ ПОНЯЛ! СДЕЛАЙ БУКВЫ ПОБОЛЬШЕ!!!111

U>

НИЧЕГО НЕ ПОНЯЛ! СДЕЛАЙ БУКВЫ ПОБОЛЬШЕ!!!111

Не надо так. Владимиру Даниэловичу — за 80.
Имейте уважение к сединам и овер50-летнему стажу в космической отрасли.

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

F>+1, однако я нашел случай удачного применения графических схем, когда ребенок стал изучать scratch
F>Он графический и с ним можно быстро создать программу и даже вполне рабочую игру.
Это не совсем удачное применение. Это просто применение для простейших случаев на начальном этапе, на scratch что то серьезное написать это проще застрелиться, как и на любом другом графическом языке. И это принципиальная проблема графических языков — они годятся только для чего то простого и на начальном этапе.

А для такой ниши, как scratch — языков до черта и больше, причем вполне успешно применяются. Например в геймдева blueprint юзают вполне успешно. Есть еще LabVIEW. Но все они крайне нишевые. Вот только не надо на такие языки сажать реальных программистов, они могут застрелиться!!!! Называется мечта всех биг боссов что программисты станут не нужны, вместо них поставим биороботов и минимальной квалификацией, сэкономим кучу денег. А результат всегда один наоборот раздувается штат, на эти графических языки приходится сажать реальных программистов, при этом им платить еще сильно больше, чтоб они не убежали.