Здравствуйте, grosborn, Вы писали:
G>Если сравнивать эти два случая, то для целей программирования дракон, как пример читаемой записи, в таком сравнении практичнее.
удивлен и озадачен
Если честно, если бы не знал квиксорт, то в дракон схеме его бы не узнал и не прочитал.
Re[4]: Язык ДРАКОН — новая идея в программировании
все таки повторю свое мнение, — в данном случае Дракон никакой не язык. Язык здесь Python, а Дракон просто средство визуализации исполнения питоновского скрипта. Для человека, который знает Python — это блок схема с практической точки зрения почти не имеет пользы, но и для человека не знакомого с Python-ом, но знакомого с Драконом, точно также вряд ли схема будет иметь практическую ценность. Представляется мне для обучения такие вещи удобны, для повседневной жизни, вряд ли.
.
Re[5]: Язык ДРАКОН — новая идея в программировании
> G>Если сравнивать эти два случая, то для целей программирования дракон, как пример читаемой записи, в таком сравнении практичнее. > > удивлен и озадачен > > Если честно, если бы не знал квиксорт, то в дракон схеме его бы не узнал и не прочитал.
Я к тому, что хаскель без комментариев это код с которым невозможно совместно работать. Его специально нужно делать читаемым. Хотя я даже сомневаюсь что это возможно. Почти так же как регулярки. Регулярки вообще крайний случай нечитабельности.
Когда пишешь для себя и опупеваешь от субственной крутизны, это одно. Когда пишешь в команде, это другое. Когда еще и приемка кода есть сторонними лицами, то хаскель думаю неприемлем вообще.
Posted via RSDN NNTP Server 2.1 beta
Забанен на рсдн за применение слова "Маргинал"
Re[2]: Язык ДРАКОН — новая идея в программировании
СМ>Какие средства язык предоставляет для организации больших программ?
СМ>Я имею в виду средства абстракции и (де)композиции алгоритмов и данных.
СМ>И как это соотносится с тем, что проектирование в первую очередь затрагивает вопросы декомпозиции задачи на слои/функции/объекты и т.п.?
СМ>Дракон предназначен только для представления алгоритмов. СМ>Всё остальное: модель данных, иерархия наследования, уровни абстракции — делается в обычном порядке средствами вашего любимого языка программирования.
Только вот как только язык не ложится на Дракон, возникают проблемы (см. Erlang)
СМ>Для проектирования статической структуры программы используются другие виды диаграмм: сущность-связь, диаграмма классов, диаграмма компонентов и прочая.
СМ>Что касается декомпозиции алгоритмов. СМ>Дракон даёт дополнительный способ декомпозиции в дополнение к обычному вызову подпрограмм. СМ>Это так называемый "силуэт". Он разбивает алгоритм на логические части, что позволяет избежать необходимости лишний раз создавать подпрограммы.
СМ>2. У Дракона есть дополнительные правила, цель которых — сделать диаграмму более предсказуемой и читаемой. СМ>Каждое из этих правил имеет объективное обоснование. СМ>Например, строгий запрет пересечения линий нужен, чтобы картинка не превратилась в кашу.
СМ>Шансов объяснить ему это всё в течение суток нет. Даю ему Дракон-схемы и через 30 минут получаю "зачøт". Немец всё понял, а ведь он Дракона-то и не видел никогда. СМ>После этого, водя пальцем по линиям и квадратиком, набросал юнит-тесты. И уже потом написал основной код и спокойно лёг спать. СМ>Результат — всё работает.
То же самое можно сказать и про правильно нарисованную схему в UML. Не говоря о том, что UML позволяет представить проблему с нескольких точек зрения.
Здравствуйте, grosborn, Вы писали:
>> G>Если сравнивать эти два случая, то для целей программирования дракон, как пример читаемой записи, в таком сравнении практичнее. >> >> удивлен и озадачен >> >> Если честно, если бы не знал квиксорт, то в дракон схеме его бы не узнал и не прочитал.
G>Я к тому, что хаскель без комментариев это код с которым невозможно совместно работать. Его специально нужно делать читаемым. Хотя я даже сомневаюсь что это возможно. Почти так же как регулярки. Регулярки вообще крайний случай нечитабельности.
Странно, квиксорт на хаскеле писал не я, но я его понимаю. К тому же, этот код один в один похож на запись квиксорта в математической нотации, читаемость которой довольно высока.
G>Когда пишешь для себя и опупеваешь от субственной крутизны, это одно. Когда пишешь в команде, это другое. Когда еще и приемка кода есть сторонними лицами, то хаскель думаю неприемлем вообще.
Если сторонние лица знакомы с программированием по бейсику, то конечно.
Re[2]: Язык ДРАКОН — новая идея в программировании
СМ>Я тоже печатаю быстрее, чем рисую. Но программы редко пишут, да часто читают. Дракон облегчает именно чтение и понимание. СМ>Рисовать сложнее хотя бы потому, что в Дракон-диаграмму надо закладывать дополнительную информацию, которая не является необходимой для выполнения. СМ>Но зато эта информация очень помогает чтению, поэтому дополнительные усилия окупаются.
На это я тоже уже отвечал:
К сожалению, исходники как раз наглядно показывают, что без поллитры и активной помощи автора в них фиг разберешься :
— Диаграммы не помещаются на экране (даже при zoom out)
— Взаимодействие между отдельными функциями (типа bad_case/foreach_current/и т.п. во всяких cs.drn и т.п.) непонятно (может они вызываются откуда-то извне? неизвестно).
— они достаточно низкоуровневы, чтобы без комментариев разобраться было уже невозможно:
Код:
set found_keywords [ gen_cpp::find_keywords $first $keywords ]
set alien_keywords [ gen_cpp::find_not_belonging $first $keywords ]
— местами это по сути псевдокод, только в визуальном обрамлении (например, alt_edit.drn -> shadow), то есть от визуальности он не выигрывает вообще ничего. В частности, для диаграмм типа alt_edit.drn -> update, если использовать паттерн матчинг (Haskell, Erlang, Nemerle), то даже текстовая запись будет не менее, а то и более наглядна
СМ>
СМ>Прогрессивный мир нынче смотрит на: метапрограммирование, зависимые типы, typesets, proof-carrying code. Крайне интересны исследования в области total functional programming.
СМ>Многое из перечисленного выше отлично работает вместе с Драконом. То же функциональное программирование, отлично сочетается с Драконом (ДРАКОН-Эрланг например).
НИфига он там не сочетается. Цитирую:
2. Перегрузка функций (наличие нескольких функций с одним именем) запрещены в DRAKON Editor'е по
политическим мотивам.
3. Ветвление логики делается только стандартными средствами Дракона, pattern matching (case of, when) для этого не используется.
На драконе даже алгоритмы с ФВП записать не удастся
P.S. Ветку с вопросами на oberoncore закрыли (потому что кому нафиг нужны неудобные вопросы?)
Поэтому будет хорошо, если вопросы, задаваемые тут, на oberoncore транслировал кто-то из участников того форума. Так что, Степан, просьба перезадать некоторые из вопросов, которые возниктнут тут, на oberoncore
А Вам это не напоминает мертворожденное дитятё? Хотя согласен применимо в узконаправленных областях, тьфу о мертвых плохо не говорят, но вся это схоластика, даж боюсь эт слово дурное — DSL употребить.... Может проще использовать SVG? И портабилити, ну и мало ли у кого руки под что заточены... Эт так комментарий, не ради флэйма...
Владимир, а чем эта идея новая?
Алгоритмические схемы существуют уже очень давно, в десятках известных и тысячах менее известных вариантах.
Связки графического представления с конкретными языками / рантаймом — тоже.
Даже если принять, что ДРАКОНовская реализация превосходит все остальные — что нового-то в этой "идее"?
Уже после прочтения заголовка темы Вас мало кто воспринимает всерьез.
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Blockly — новый графический язык от гугла. На OpenNet есть небольшое описание. Разработка, вроде как, задумывается для реального применения. Вместо блок-схем используются блоки как в пазлах, выглядит гламурно:
Был бы интересен симбиоз направленного графа ДРАКОН-а и этих "пазлов"...
Здравствуйте, FR, Вы писали:
FR>В обсуждении на OpenNet наткнулся на ссылку на конкурента (в прямом смысле создан в 70 — 80 в СССР и FR>тоже использовался ракетчиками ) Р-технологии
А я все никак не мог вспомнить, пока читал тему, как эта технология называется. Боюсь наврать, эксперименты на ЕС ЭВМ проводились с Фортраном, PL/1 и, возможно, Ассемблером. Я даже распечатки таких схем видел с кодом внутри. Ну не было там графических дисплеев. Я не знаю, как вводились эти схемы.
Языки, если не вру, назывались графический Фортран, графический PL/1. Google по запросу "графический Фортран" привел к Графору, который, имея прямое отношение как к Фортрану, так и к графике, никак не связан с темой обсуждения. Вот я ничего и не нашел.
Интересно, те, кто постарше, например, LaptevVV, в курсе, что там происходило и есть ли этому какое-нибудь развитие? Использовалась ли эта Р-технология промышленно?
Здравствуйте, PSV100, Вы писали:
PSV>Blockly — новый графический язык от гугла. На OpenNet есть небольшое описание. Разработка, вроде как, задумывается для реального применения. Вместо блок-схем используются блоки как в пазлах, выглядит гламурно:
Тот же Scratch, только не надо ничего скачивать. ИМХО для детей только. Либо для обучения на первых курсах, после чего про него забываем, как страшный сон.
Никто в здравом уме такие языки для промышленного применения использовать не будет. Хоть это будет трижды гугол — если будут пытаться на это пересадить программистов реальных, ничего у них не выйдет. Если попробовать посадить непрограммистов — попробовать конечно можно, в теории может и получиться, но я как то сомневаюсь, что получится даже у гугла. В лучшем случае кончится тем же, что и всегда — непрограммисты на этом ужасе черти что наваяют, логика разрастется до неприличных размеров, все будет черти как запутанно, что сам черт голову сломит, и далее за бешенные деньги этот ужас посадят разгребать программистов, которые будут долго и сильно материться.
Здравствуйте, FR, Вы писали:
FR>В обсуждении на OpenNet наткнулся на ссылку на конкурента (в прямом смысле создан в 70 — 80 в СССР и FR>тоже использовался ракетчиками ) Р-технологии
FR>На первый взгляд и судя по схемам здесь http://glushkov.org/?page_id=59 FR>гораздо нагляднее (во всяком случае для программиста) Дракона.
Действительно, очень может быть, что Р-технология нагляднее Дракона. Как-то не попадалась информация о ней раньше, и, скорее всего, очень жаль, что так получилось. Я сейчас Дракон изредка использую, но только для документации, а точнее — для всяких набросков на бумаге, чтобы с коллегами что-то обсудить или со сторонними спецами-непрограммистами в прикладной области (подтверждаю, что все всё понимают без лишних слов, можно говорить на одном языке). Так как многие из нас "выращены" на блок-схемах, то для "разборов полётов" использовались всякие рисунки, напоминающие блок-схемы, со стрелками туда-сюда и как попало. Когда начали рисовать схемки более-менее похожие на Дракон — жизнь упростилась: направленный граф и отсутствие пересекающихся линий реально помогают, идея простая и эффективная (спасибо Паронджанову).
Сейчас немного посмотрел на Р-технологию. Что понравилось на фоне Дракона:
— отсутствие явных блоков, т.е. всяких прямоугольников с ромбиками и пр., т.е. это не блок-схемы. Их банально задалбывает рисовать на бумаге, а пользоваться графическим редактором — ещё более муторное дело. В Р-технологии нагружаются ребра графа, текст над и под ребрами как-то меньше влияет на восприятие текста в соседних "блоках", например, нет такого желания, как сделать "прямоугольники" одинакового размера. И, имхо, для Р-графов проще реализовать поддержку в текстовом редакторе для их удобного ввода в псевдографике (что крайне проблематично для Дракона и прочих блок-схем);
— схемы, в основном, "продвигаются" слева-направо, что удобно при альбомной ориентации, особенно при широкоформатных мониторах;
— Р-графы лучше приспособлены для ветвления, особенно при множественном выборе. Имхо, также здесь возможно проще изобразить паттерн-матчинг;
— правил в Р-технологии ещё меньше, чем в Драконе. При этом схемы выглядят покомпатнее, с большим запасом для показа содержательной информации. Но здесь есть явные стрелки и возможно пересечение линий, насколько это ухудшает восприятие — пока сложно сказать.
Короче говоря, очевидно, что графы РТ задумывались как замена блок-схемам, и на первый взгляд не плохая. В инете очень мало информации о проекте (здесь пару слов про Р-технологию, здесь можно прочитать дифирамбы для неё). Жаль нет толкового сравнения с Драконом, реально интересно и мнение Владимира Даниловича.
Здравствуйте, PSV100, Вы писали:
PSV>Короче говоря, очевидно, что графы РТ задумывались как замена блок-схемам, и на первый взгляд не плохая. В инете очень мало информации о проекте (здесь пару слов про Р-технологию, здесь можно прочитать дифирамбы для неё). Жаль нет толкового сравнения с Драконом, реально интересно и мнение Владимира Даниловича.
Здравствуйте, elmal, Вы писали:
PSV>>Blockly — новый графический язык от гугла. На OpenNet есть небольшое описание. Разработка, вроде как, задумывается для реального применения. Вместо блок-схем используются блоки как в пазлах, выглядит гламурно:
E>Тот же Scratch, только не надо ничего скачивать. ИМХО для детей только. Либо для обучения на первых курсах, после чего про него забываем, как страшный сон. E>Никто в здравом уме такие языки для промышленного применения использовать не будет. Хоть это будет трижды гугол — если будут пытаться на это пересадить программистов реальных, ничего у них не выйдет. Если попробовать посадить непрограммистов — попробовать конечно можно, в теории может и получиться, но я как то сомневаюсь, что получится даже у гугла. В лучшем случае кончится тем же, что и всегда — непрограммисты на этом ужасе черти что наваяют, логика разрастется до неприличных размеров, все будет черти как запутанно, что сам черт голову сломит, и далее за бешенные деньги этот ужас посадят разгребать программистов, которые будут долго и сильно материться.
Гугловцы, вроде как, заявляют о применении языка для относительно небольших сценариев. Имхо, у них прицел на создание расширений для своих сервисов. Где-то говорилось, что есть пример создания фильтра писем для Gmail. Такие подходы вполне могут оправдать себя.
