Здравствуйте, vdimas, Вы писали:
V>PCAD, ORCAD, CIRCAD, LabView, Mathcad, Matlab+Simulink.
Про PCAD ничего не знаю, но остальные продукты не помогают в решение проблем общего программирования о котором писал ТС. В отличие от ФП, зависимых типов, DSL-ов, динамики, мета-программирования и т.д. о которых принято говорить на этом форуме. Впрочем для меня уже понятно, что Дракон это просто аналог LabView для визуализации и отладки логики контроллеров оборудования инженерами.
Re[30]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, grosborn, Вы писали:
G>Вот кстати хорошее замечание. Могу указать на слабое место, которое и приводит к падению спутников. Есть условно говоря два вида тестирования этих комплексов, главная часть — тесты которые пишет инженер. Он тестирует функциональность, поведение и ряд параметров, по которым и определятся работоспособность блоков и системы в целом. Эти тесты это даже не одна, а ряд совершенно отдельных задач, которые выполняются еще и другими людьми. Инженер написал тесты, а другой может проектировать для него стенды и в свою очередь давать задание другим программистам для написания программы для испытаний.
G>И вторая часть — тестирование самой программы которую пишет программист. Вот тут косяк, программиста в этом деле обычно или не контролируют достаточно, или контролируют внутри отдела. А тесты реализаций алгоритмов не в комплексе с программой испытаний инженера. Инженер не может создать программу испытаний для программиста, программист в свою очередь не владеет темой в комплексе. И даже по ТЗ написав безошибочную программу, в работающем комплексе возникают ошибки и сбои. G>И это косяк декомпозиции.
Мне кажется там тестируется всё в комплексе на стенде, при этом стараются поймать все типы ошибок и аппаратные и программные. Если набор стендовых тестов полный и адекватный это вполне возможно.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[14]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, novitk, Вы писали:
N>Про PCAD ничего не знаю, но остальные продукты не помогают в решение проблем общего программирования о котором писал ТС. В отличие от ФП, зависимых типов, DSL-ов, динамики, мета-программирования и т.д. о которых принято говорить на этом форуме. Впрочем для меня уже понятно, что Дракон это просто аналог LabView для визуализации и отладки логики контроллеров оборудования инженерами.
Я бы не сказал, что аналог LabView. LabView заточено на схемы. А Дракон в принципе по наглядности, если правильно использовать, вполне неплохая нотация для документирования и постановки задач по крайней мере в своей предметной области. По крайней мере те примеры, что идут в книге — они действительно достаточно наглядны. По крайней мере UML мне однозначно гораздо меньше нравится. И именно для инженеров — специалистов в предметной области, но не программистов, я вполне допускаю, что язык очень и очень удобен. Книжка вроде тоже весьма неплоха (смотрел мельком, вполне возможно, что даже прочитаю в будущем), читается хорошо, с картинками — красота. И вполне допускаю, что для своей предметной области он вполне неплох. Правда я далеко не уверен, что получится бухгалтеров научить этому языку, все таки язык однозначно для людей с техническим складом ума . Но вот аналитиков обучить языку вполне можно, и вполне вероятно, что после обучения они вполне будут делать гораздо меньше ошибок, да и их творчество возможно будет наконец читать не сильно напрягаясь. А то, сколько не видел аналитиков — те так лажают в спеках, что нет слов.
Правда говорить о том, чтоб использовать этот язык для массового применения и для общего именно программирования не стоит. ТС просто крайне узко специализирован, опыт весьма специфический, в результате чего просто довольно сильно отстал от современного понятия общего программирования. Но для некоторой узкой ниши ИМХО язык может оказаться достаточно неплохим даже в настоящее время. Например для обучения непрограммистов алгоритмам. А также для использования непрограммистами. Если посадить за этот язык современного программиста — да, будет черти какой мат, ибо проблем от использования будет на порядок больше, чем пользы. Хотя, многих юниоров, привыкших писать спагетти, следовало бы посадить — пусть сидят с ограниченными возможностями, пока не научатся мыслить в нужном направлении.
Так что на автора наезжать не надо. Гораздо более умные вещи пишет (если отфильтровать некоторую излишние эпитеты), чем создатель ультракороткого языка программирования.
Re[15]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, elmal, Вы писали:
E>А Дракон в принципе по наглядности, если правильно использовать, вполне неплохая нотация для документирования и постановки задач по крайней мере в своей предметной области. По крайней мере те примеры, что идут в книге — они действительно достаточно наглядны. По крайней мере UML мне однозначно гораздо меньше нравится.
То есть ты рассматриваешь Дракон не для программирования, а лишь для документации.
Чем же именно он лучше для этих целей чем диаграммы поведения UML?
Re[14]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, novitk, Вы писали:
V>>PCAD, ORCAD, CIRCAD, LabView, Mathcad, Matlab+Simulink. N>Про PCAD ничего не знаю, но остальные продукты не помогают в решение проблем общего программирования о котором писал ТС.
Значит, про остальные тоже ничего не знаешь.
LabView, Mathcad, Matlab+Simulink.
Эти инструменты используется как вспомогательные к "обычному программированию", резко увеличивая производительность для многих прикладных направлений.
N>В отличие от ФП, зависимых типов, DSL-ов, динамики, мета-программирования и т.д. о которых принято говорить на этом форуме.
Мало ли где что принято. Реальная проблема стоит в наличии пропасти м/у инструментами расчета/моделирования и собственно программированием. Этой пропасти быть не должно. Сама пропасть состоит исключительно в плохопереносимом и плохоразбираемом текстовом представлении исходного кода программ на современных популярных языках и ни в чем больше. Реально ситуация на сегодня такова, что сами по себе текстовые исходники представляют из себя неорганизованный сброд текстовых файлов. Чтобы что-то полезное из них извлечь, необходимо отталкиваться от файлов проектов, в котором упоминаются не только исходники, но так же их зависимости, флаги компиляции и все такое прочее, что иногда кардинальным образом влияет на семантику этих несамодостаточных текстовых файлов. Получается очевидная проблема, что кол-во языков надо умножать на кол-во форматов файлов проектов, чтобы как-то это окучить. Но даже и этого мало, бо в том же Linux зачастую многое, относящееся к компиляции, задается переменными окружения конкретного сеанса оболочки. А это залет, курсант — через это вообще никак не перепрыгнуть.
В общем, были бы текстовые файлы популярных языков программирования самодостаточные, можно было бы еще о чем-то говорить. А так, ввиду врожденной ограниченности текстового языка лишь синтаксисом конкретного языка, имеем что имеем — необходимость во внешней обслуживающей инфраструктуре.
Дракон можно рассматривать как попытку организации такой инфраструктуры.
N>Впрочем для меня уже понятно, что Дракон это просто аналог LabView для визуализации и отладки логики контроллеров оборудования инженерами.
Ничего тебе не понятно и близко.
Re[16]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, novitk, Вы писали:
N>То есть ты рассматриваешь Дракон не для программирования, а лишь для документации. N>Чем же именно он лучше для этих целей чем диаграммы поведения UML?
Тем, что они уж сильно ограничены.
Re[31]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, pagid, Вы писали:
P>Мне кажется там тестируется всё в комплексе на стенде, при этом стараются поймать все типы ошибок и аппаратные и программные. Если набор стендовых тестов полный и адекватный это вполне возможно.
В свое время писали о сбоях каких-то космических устройств, произошедших из-за каши из метрических и дюймовых величин. Такие ошибки на стенде отловить не всегда реально.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[32]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, Ops, Вы писали:
Ops>В свое время писали о сбоях каких-то космических устройств, произошедших из-за каши из метрических и дюймовых величин.
Припоминаю подобноные истории про авиацию. Может у американцев или европейцев было что-то и в космонавтике.
Ops> Такие ошибки на стенде отловить не всегда реально.
Не вижу особого отличия от других видов ошибок.
... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>
Re[16]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, novitk, Вы писали:
N>То есть ты рассматриваешь Дракон не для программирования, а лишь для документации.
Естественно, лично я в здравом уме пытаться программировать на визуальных языках не буду больше даже пытаться, на любом. Даже на сверхпроработанном, в развитие которого вбросили 100 миллиардов долларов, и в котором ни единой ошибки и который просто предугадывает то, что мне нужно сделать. Ибо текстом я сделаю гораздо быстрее и качественней.
В случая водопада без итераций Дракон можно рассматривать частично и для программирования. Естественно частично. Специалист по предметной области нарисовал диаграмку, диаграмку 10 раз проверили — она верна, изменений не будет. Далее нагенерили шаблон (возможно вместе с значительным количеством кода), и далее уже работаем с кодом и отлаживаем код. N>Чем же именно он лучше для этих целей чем диаграммы поведения UML?
А ты попробуй научить далекого от программирования специалиста в предметной области нарисовать достаточно читаемую диаграмму поведения. Ведь будет однозначно мешанина из блоков и стрелочек, причем стрелочек с пересечением. Да и даже если просто программиста заставить рисовать это все — тоже будет мешанина стрелочек. А в Драконе интересен не сколько сам язык, сколько книга по его использованию. Написана вполне даже неплохо. Насколько я понял, нотации Дракона проработаны именно таким образом, чтоб избежать мешанины. Если нотация достаточно проста, в тоже время достаточно выразительна, плюс если заточена именно под определенный класс задач, плюс если есть хорошая документация, плюс если пользоваться средой достаточно удобно и она сразу же подталкивает тебя в нужном направлении — для целей документирования получается весьма неплохая вещь. Вполне допускаю, что некоторым непрограммистам будет даже удобно на этом полностью программы писать.
Re[27]: Язык ДРАКОН — новая идея в программировании
На стр. 50 рис. 45 показан алгоритм ИСТОРИЯ С КАШЕЙ.
Этот алгоритм имеет два синтаксиса:
• Текстовый синтаксис;
• Графический синтаксис.
Графический синтаксис является математически строгим.
Текстовые надписи написаны на естественном языке, то есть неформально. В Графит-Флоксе это недопустимо.
Проведем формализацию, то есть заменим естественный язык на формальный язык Графит-Флокс.
Покажем это на примере надписи «Каша подгорела?».
На формальном языке эта надпись превращается во флокс-идентификатор
ПЛ1ЩФ.КАША.ГОРЕЛ
Таким образом, текст на русском языке Каша подгорела? преобразован в математически строгий идентификатор ПЛ1ЩФ.КАША.ГОРЕЛ
Идентификатор состоит из трех частей:
• Префикс ПЛ1ЩП
• Разделитель . (точка)
• Смысловая часть КАША.ГОРЕЛ (не более 10 символов)
Префикс состоит из 5 символов, является позиционным.
П — признак
Л —логический
1 — бортовой компьютер Бисер
Щ — аппаратура спутниковой навигации
Ф — Фрегат (разгонный блок космических аппаратов Фрегат)
Если в 3-й позиции идентификатора стоит 5, это означает наземный компьютер Бисер.
Оператор ПЛ5ЩП.КАША.ГОРЕЛ := ПЛ1ЩП.КАША.ГОРЕЛ
означает, что указанный признак пересылается из бортового компьютера в наземный. (Признак однобитовый)
Еще один пример.
Данный алгоритм называется ИСТОРИЯ С КАШЕЙ
После формализации получим идентификатор алгоритма АП1ЩП.КАША
АП — означает алгоритм-процедура.
Если написать АИ1ЩП.КАША — это означает не алгоритм-процедура, а алгоритм-исполнитель. Исполнитель (на нашем жаргоне) — это головной алгоритм, получающий управление от диспетчера режима.
И так далее.
Теперь вернемся к вопросу
Мне, например, весьма интересно, как на практике алгоритм "ИСТОРИЯ С КАШЕЙ" будет уведомлять родительский алгоритм о том, что каша подгорела.
Ответ такой. Уведомлять родительский алгоритм о том, что каша подгорела, НЕ НУЖНО. Поскольку все идентификаторы глобальные. Путаница не возникает. Потому что префикс наводит строгий порядок и задает четкое распределение ответственности.
Примечание. В Графит-Флоксе все идентификаторы имеют математически строгие определения. Я здесь эту проблему не рассматриваю.
Сколько всего идентификаторов? Десятки тысяч.
Все идентификаторы и их определения описываются во флокс-описаниях (флокс-таблицах).
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Ответ такой. Уведомлять родительский алгоритм о том, что каша подгорела, НЕ НУЖНО. Поскольку все идентификаторы глобальные. Путаница не возникает. Потому что префикс наводит строгий порядок и задает четкое распределение ответственности.
Вот что то подобное я и предполагал. Дело не в путанице. Дело не в разделении ответственности. Глобальные идентификаторы — это крайне ужасно. Про параллелизм можно забыть сразу. А современная тенденция в программировании, и задача, которую не могут пока достаточно эффективно решить — это как максимально делать алгоритмы параллельными. В случае с глобальными идентификаторами хотя бы состояний — без шансов. Как мне сварить параллельно N каш? Да и даже если без параллелизма — тоже будут весьма интересные эффекты при многократном вызове какого либо алгоритма из разных мест.
И это даже мелочь. По сравнению с тем, что любой может случайно по невнимательности изменить значение. Или, я надеюсь, не может, и эти идентификаторы только на чтение, и устанавливать их можно только в том месте, где они определены? Хотя бы есть правило на ограничения доступа? Что родитель имеет доступ только к идентификаторам только непосредственно тех алгоритмов, который он только что вызвал? Если так, небольшое облегчение конечно. Я конечно предполагаю, что работа организована таким образом, чтобы параллелизм не допускать, а также вы нашли средства и методы, чтобы со всем этим жить, но на практике уже много десятков лет существуют более эффективные средства.
ВП>Сколько всего идентификаторов? Десятки тысяч.
Еще ужаснее. Нет, на современных языках тоже можно считать, что идентификаторов десятки тысяч. Тоже группировка по неймспейсам, пакетам, модулям. Но по крайней мере ограничения доступа и видимости есть, в результате эти десятки тысяч превращаются просто в сотни, а то и меньше. От глобальных переменных начали избавляться наверно в 50-х годах. Сейчас 2012.
Re[33]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, pagid, Вы писали: P>Припоминаю подобноные истории про авиацию. Может у американцев или европейцев было что-то и в космонавтике.
История очень известная http://www.osp.ru/os/1998/06/179592/
Re[33]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, pagid, Вы писали:
Ops>>В свое время писали о сбоях каких-то космических устройств, произошедших из-за каши из метрических и дюймовых величин. P>Припоминаю подобноные истории про авиацию. Может у американцев или европейцев было что-то и в космонавтике.
Это был epic fail с Mars Climate Orbiter.
Впрочем, у СССР был не менее facepalm'овый fail с неправильной командой Фобосу-1.
Sapienti sat!
Re[12]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, novitk, Вы писали:
N>>>И это даже не касаясь высказанной здесь многократно точке зрения о полной ненужности визуального программирования, как такового. V>>Высказывались люди, которые обобщали свой субъективный опыт и характер решаемых задач на отрасль в целом. Без комментариев, как говорится. N>Я не очень понимаю, какую позицию ты отстаиваешь в споре с Cyberax-ом. Он вроде всего лишь выступает против применения визуального подхода по сравнению с текстовыми для решения реальных задач из за неадекватного инструментария с которым он имел "счастье" работать. Если у тебя есть другой опыт, расскажи. Только не абстрактно, а конкретно про используемые тобой инструменты и задачи.
Я не считаю, что адекватный инструментарий для графического программирования вообще возможен. Попытки за 50 лет его написать (включая даже гениев IDE из JetBrains) оказались безуспешны. Тогда как текстовые языки, IDE и вообще инструментарий для работы показывают постоянное улучшение.
Так что можно сделать вывод, что графические языки — это тупик.
Понятно, что в ряде ниш они полезны и нужны. Скажем, graphedit очень удобен при экспериментах с multimedia в Винде.
Sapienti sat!
Re[3]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, ins-omnia, Вы писали:
V>> Не знаю ничего насчет именно языка ДРАКОН,... ... управление компьютером лет через 20 будет выглядеть как комбинированное использование жестов руками в воздухе, движения глаз и губ, мимики лица, и голосовых команд. При этом будет достигнута очень важная цель — скорость взаимодействия между мозгом и компьютером возрастет на порядок V>> и возможно, любая идея, только зародившаяся в голове, сможет обретать свое представление в формальных схемах.
IO>Уже сейчас всё гораздо круче: большая часть идей, которые зарождаются у людей в голове, заранее существует в виде формальных схем, инсталируемых в головы через зомбоящик.
Если бы это было бы так, то тогда инсталляторы через зомбоящик — продюсеры сценаристы, режиссеры и их заказчики во власти, имели бы свои формальные схемы, для создания сценариев и передач,
то есть существовали бы эти схемы еще до того как возникли. пришли к противоречию.
Re[15]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, vdimas, Вы писали:
V>Значит, про остальные тоже ничего не знаешь.
Хамство не красит человека.
V>Эти инструменты используется как вспомогательные к "обычному программированию", резко увеличивая производительность для многих прикладных направлений.
Все это преминимо только для R&D, как и Excel. В коробку это нормальные люди не кладут.
V>В общем, были бы текстовые файлы популярных языков программирования самодостаточные, можно было бы еще о чем-то говорить. А так, ввиду врожденной ограниченности текстового языка лишь синтаксисом конкретного языка, имеем что имеем — необходимость во внешней обслуживающей инфраструктуре.
Smalltalk и с песней. Файлов нет, все модели прямо в памяти, синтаксиса нет. Помогает, но не сильно.
V>Дракон можно рассматривать как попытку организации такой инфраструктуры.
Дракон пока можно вообще не рассматривать за отсутсвием в нем новых идей.
Re[16]: Язык ДРАКОН — новая идея в программировании
Чтобы уяснить одну из основных идей языка Дракон, необходимо глубже познакомиться с понятием "симультанное восприятие".
Симультанное восприятие окружающего мира формировалось в течение многих миллионов лет — на протяжении всей эволюции человеческого зрительного аппарата и мозга.
Почему симультанное восприятие столь важно?
Мне кажется, победит тот разработчик языков, кто сумеет в максимально возможной степени использовать мощные механизмы симультанного восприятия, образовавшиеся за миллионы лет эволюции.
Скорость чтения никак ни является лимитирующим фактором при обучении, так как скорость
понимания или усвоения на порядок меньше.
Скорость чтения обычного текста вполне поднимается в разы или даже на порядок, что
демонстрируют те кто освоил скорочтение. Но толку от этого мало, быстрее усваивать
не получается.
Ну и спорным является и то что чтение обычного текста не является симультанным, те же
практики скорочтения показывают и доказывают обратное
По рзелульаттам илссеовадний одонго анлигйсокго унвиертисета, не иеемт занчнеия,
в кокам пряокде рсапожолены бкувы в солве. Галвоне, чотбы преавя и пслоендяя бквуы
блыи на мсете. Осатьлыне бкувы мгоут селдовтаь в плоонм бсепордяке, все рвано ткест
чтаитсея без побрелм. Пичрионй эгото ялвятеся то, что мы не чиатем кдаужю бкуву по
отдльнотси, а все солво цликеом.
Re[18]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, FR, Вы писали:
FR>1. Скорость чтения никак ни является лимитирующим фактором при обучении, так как скорость понимания или усвоения на порядок меньше.
FR>2. Скорость чтения обычного текста вполне поднимается в разы или даже на порядок, что демонстрируют те кто освоил скорочтение. Но толку от этого мало, быстрее усваивать не получается.
Вы совершенно правы. Но ведь я говорю не об этом.
Я говорю: эргономичная графика воспринимается быстрее, чем текст за счет симультанных механизмов.
FR>Ну и спорным является и то что чтение обычного текста не является симультанным, те же практики скорочтения показывают и доказывают обратное
Вы правы. При чтении обычного текста используются оба механизма сукцессивный и симультанный.
Но! Степень симультанности РАЗНАЯ. При чтении эргономичной графики эта степень много выше.
3. Обучение программированию является важной задачей. Но эта за-
дача касается сравнительно небольшого числа людей.
Обучение программированию не может и не должно быть массо-
вым.
4. Что касается алгоритмизации (понимаемой, как овладение алгорит-
мическим мышлением), то эта задача может и должна быть предме-
том массового обучения.
5. Сегодня обучение алгоритмизации не рассматривается как само-
стоятельная задача, необходимая обществу.
6. Принято считать, что алгоритмизация – это часть курса програм-
мирования и вне последнего не имеет ценности для общества.
7. Это неверно. Частично формализованные алгоритмы способны
принести большую пользу медикам, биологам, работникам госу-
дарственного, муниципального и корпоративного управления, гу-
манитариям и многим другим людям, которым не нужно знать про-
граммирование, но нужно уметь мыслить алгоритмически.
8. Таким образом, перед системой образования возникает принципи-
ально новая масштабная задача: организовать обучение алгоритми-
ческому мышлению для непрограммистов. То есть для подавляю-
щего большинства специалистов.
