Здравствуйте, PSV100, Вы писали:
PSV>Имхо, отсутствие "жж-ж-ж" по этому поводу не просто так...
Причина может быть, например, в том, что Р-технология развивалась и использовалась на Украине.
хороший язык и отлично что на нем пишется софт для космоса,
на современных языках такого бы наворотили бы, что падолобы всё на головы
способ записи алгоритмов который не допускает тупых ошибок и холиваров на какой строке скобку ставить
надо развивать и не усложнять его, чтобы никто не выстреливал себе в ногу
PSV>К сожалению, не могу посмотреть подробности в соответствующей теме на форуме oberoncore, ибо меня там не регистрируют.
А там и не стоит появляться. Сначала там в подробностях разберут твою личность[1], потом будут вопрошать «а кто ты такой», потом модератор потрет самые яркие высказывания «уважаемых участников» (чтобы не портить им карму), тему закроют, а тебя забанят якобы за неоднократное нарушение правил.
[1] Например: Некто Тышов, типа гуру, нашел мое стихотворение восьмилетней давности про флуд
, нашел потом его на моем сайте, связал это с мои ником на форуме оберонкор, полностью процитировал это стихотворение и спросил: «вы сюда поразвлекаться пришли»? Ни одного ответа ни на один вопрос он так и не предоставил, продолжая выяснять, где я живу, какие сайты я веду и т.п. Лезть в этот застарелый адъ почти поголовно страдающих завышенным ЧСВ маразматиков не советую.
Здравствуйте, BrainSlug, Вы писали:
BS>все таки повторю свое мнение, — в данном случае Дракон никакой не язык.
........................................................................... BS> Представляется мне для обучения такие вещи удобны, для повседневной жизни, вряд ли.
Уважаемый BrainSlug!
ДРАКОН ориентирован в значительной мере на непрограммистов. Для них вопрос "язык или не язык" не интересен.
Поясню.
Точнее, не поясню, а просто приведу комментарий маркетолога Наталии Корабельщиковой. На днях она оставила этот комментарий на моей странице в Фейсбуке.
"День добрый! Я Вас не забыла.
Я сейчас пишу алгоритм составления ассортиментной матрицы для отдела маркетинга оптовой фирмы.
Пока хочу сказать, что чем дальше влезаю в Дракон, тем больше убеждаюсь, что этот язык вовсе не для домохозяек.
Более того, скажу как маркетолог, этот язык и вообще семейство языков ни в коем случае нельзя позиционировать как "язык для домохозяек", это сведет в будущем на нет его ценность в глазах возможных потребителей.
Тут крайности какие то прослеживаются — то язык программирования "для бурана", то "для домохозяек"...
Надо бы ему другое позиционирование сформулировать....
Я подумаю.
Вообще, это намного круче и понятнее, чем системы описания бизнес-процессов! Правда, я недостаточно хорошо знаю рынок систем описания бизнес-процессов, чтобы делать однозначные выводы.
Но уже то, что я уже накропала для отдела розницы, отлично разбирают малообразованные и низкооплачиваемые менеджеры отдела... Это просто удивительно.
Особенно приятно, что часто используемых фигур в этом языке совсем не много, очень легко запоминаются и читается схема тоже легко.
Здравствуйте, PSV100, Вы писали:
PSV>Blockly — новый графический язык от гугла. На OpenNet есть небольшое описание.
Спасибо за ссылку. Я обратил внимание на это:
Один из разработчиков языка Нил Фрейзер (Neil Fraser) так описывает цели создания языка: ”Эта концепция прошла очень длинный путь, от Ассемблера к Фортрану, затем к C++ и к Python, и наконец, это Blockly. Это попытка подняться на ещё более высокий уровень абстракции, чтобы лишить программирование кастовости и закрытости, сделать его более естественным и доступным для как можно более широкого круга лиц”.
Точнее, я обратил внимание не на весь этот отрывок, а только на вторую фразу:
Это попытка подняться на ещё более высокий уровень абстракции, чтобы лишить программирование кастовости и закрытости, сделать его более естественным и доступным для как можно более широкого круга лиц”.
Я готов подписаться под каждым словом Нила Фрейзера. Потому что:
1. ДРАКОН — это попытка лишить программирование кастовости.
2. ДРАКОН — это попытка лишить программирование закрытости.
3. ДРАКОН — это попытка сделать алгоритмизацию (а иногда и программирование) естественными и доступными для как можно более широкого круга лиц.
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Точнее, я обратил внимание не на весь этот отрывок, а только на вторую фразу:
ВП>
ВП>Это попытка подняться на ещё более высокий уровень абстракции, чтобы лишить программирование кастовости и закрытости, сделать его более естественным и доступным для как можно более широкого круга лиц”.
ВП>Я готов подписаться под каждым словом Нила Фрейзера. Потому что:
ВП>1. ДРАКОН — это попытка лишить программирование кастовости.
ВП>2. ДРАКОН — это попытка лишить программирование закрытости.
ВП>3. ДРАКОН — это попытка сделать алгоритмизацию (а иногда и программирование) естественными и доступными для как можно более широкого круга лиц.
Владимир Данилович, в программировании нет никакой кастовости и закрытости. Эта такое же ремесло, коих множество в человеческой деятельности, как и медицина, например, причём в отличие от медицины гораздо менее "кастовое" (вполне реально заниматься профессиональной программистской деятельностью не имея специализированного образования). Подобная реклама языка программирования на этом форуме (форуме программистов) может вызвать всплеск негативных эмоций (что Вы уже успели заметить, к сожалению). Здесь все в состоянии понять сущность ДРАКОНа. Вы создали хороший "аспирин", которым могут пользоваться обычные люди для несложных "медицинских процедур" без "врачебной" помощи, а также он полезен и "медикам", но всех потребностей "медработников" ДРАКОН не удовлетворит. И, как и во многих отраслях, для серьёзного "хирургического вмешательства" без "врачей" уже ни как не обойтись.
Пользуясь случаем, хочу сказать спасибо за ДРАКОН, это хорошее средство для употребления блок-схем.
И попутный вопросик по поводу обсуждаемой рядом Р-технологии. Я позволю себе предположить, что Вам она вполне знакома. Каково Ваше мнение/отношение/критика ?
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Я готов подписаться под каждым словом Нила Фрейзера. Потому что:
ВП>1. ДРАКОН — это попытка лишить программирование кастовости.
ВП>2. ДРАКОН — это попытка лишить программирование закрытости.
ВП>3. ДРАКОН — это попытка сделать алгоритмизацию (а иногда и программирование) естественными и доступными для как можно более широкого круга лиц.
Алгоритмы и Паскаль дают школьникам в 9м классе. Какая уж тут кастовость, закрытость и недоступность? http://www.5byte.ru/9/
Здравствуйте, samius, Вы писали:
S>Алгоритмы и Паскаль дают школьникам в 9м классе. Какая уж тут кастовость, закрытость и недоступность? S>http://www.5byte.ru/9/
А сколько процентов школьников это осиливают хотя б на 3 объективные балла? Максимум 5 процентов.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, samius, Вы писали:
S>>Алгоритмы и Паскаль дают школьникам в 9м классе. Какая уж тут кастовость, закрытость и недоступность? S>>http://www.5byte.ru/9/ E>А сколько процентов школьников это осиливают хотя б на 3 объективные балла? Максимум 5 процентов.
Я не обладаю такой статистикой, но хорошо, пусть будет 5%. Но такой процент ничего не говорит о недоступности. Сколько по вашему процентов осиливают программу по математике, физике, химии на те же объективные 3 балла? Не думаю, что существенно больше. Ну, пусть даже 25%, хотя вряд ли. Даже если 25%, то это от того что родители наседают на эти предметы посильнее, да и учителя сильные по ним имеются. С информатикой у нас пока печалька.
Предлагаю провести мысленный экспримент. Заменим блок-схемы на Дракон. Сильно ли вырастет процент осиливших программу по информатике за 9-ый класс на объективные 3 балла?
Уверен, что он едва ли всколыхнется.
Но я таки опровергал тезис о кастовости, закрытости и недоступности. То что алгоритмы и Паскаль дают ВСЕМ в 9м классе, по моему, свидетельствует об открытости, доступности и отсутствии каких-либо каст. А то что от учеников информатику не требуют так же как математику — так это другими словами называется.
Здравствуйте, PSV100, Вы писали:
PSV>Здравствуйте, VladZharinov, Вы писали:
PSV>>>Был бы интересен симбиоз направленного графа ДРАКОН-а и этих "пазлов"...
VZ>>Такое, IMHO, возможно — говорил здесь применительно к похожей среде — Скретчу. Как ещё это можно развить — на этой странице. Конструктивная критика приветствуется.
PSV>К сожалению, не могу посмотреть подробности в соответствующей теме на форуме oberoncore, ибо меня там не регистрируют. Лично я под симбиозом графа ДРАКОН-а и пазлов подразумеваю лишь техническую "улучшалку" условного ДРАКОН-редактора: вместо вставки в блоках непосредственно текста , описывающего действия, можно "лепить" пазлы (там, где это уместно, и эти "пазлы" не должны указывать на блок "if", "for" и т.п., т.е. только пазл-действия или определения).
Как я понял, речь из перечисленного мной идёт об одном посте (связанном по ссылке). Там, в сущности, развита та же идея об "улучшении" редактора, исчисляющего графы. За счёт эквивалентного изображения кроссов (и схем и составных атомов) и простых атомов как скретч-пазлов. Остальные посты в открытых темах и регистрации не требуют. Как я понял, Вы уже и зарегились на Оберонкоре, так что вроде как можете всё читать (если нет, можно перепостить сюда что-то, но не всем, наверное, стоит наполнять форум ?..
по источникам — что имеет отношение и к Вашему интересу к сравнениям. В общем он прав — то, что сейчас представлено, в основном: 1) содержит лишь упоминания техноязыка; и/или 2) почти или совсем не даёт материал для ответов на те именно вопросы, которые он поставил. Но. Некоторые исключения, IMHO, имеются. Думаю, это: 1) доклад, где как раз приложение шампур-схем к потокам управления разбирается; 2) книга, где именно есть сравнение разных графических нотаций для программирования УВК реального времени.
О некоторых других Ваших мыслях в новой теме, т.к. они туда и относятся больше.
Are visual program control flow diagrams and languages which support that used for larger serious programs? Why not? They seem like a nice overview of the code.
In the thread What software programming languages were used by the Soviet Union's space program? a visual language is mentioned (Drakon) and I wondered why such approaches aren't used more often?
Is there nothing a visual control flow representation (I don't mean class diagrams etc.) which are 1-to-1 with code can help compared to typing in letters in an editor?
Здравствуйте, VladZharinov, Вы писали:
VZ>Как я понял, речь из перечисленного мной идёт об одном посте (связанном по ссылке). Там, в сущности, развита та же идея об "улучшении" редактора, исчисляющего графы. За счёт эквивалентного изображения кроссов (и схем и составных атомов) и простых атомов как скретч-пазлов. Остальные посты в открытых темах и регистрации не требуют. Как я понял, Вы уже и зарегились на Оберонкоре, так что вроде как можете всё читать (если нет, можно перепостить сюда что-то, но не всем, наверное, стоит наполнять форум ?..
VZ>Да, в отношении [...]
Да, я не мог просмотреть все темы на Оберонкоре, но уже всё доступно. И прочитал также указанные статьи. Спасибо.
Здравствуйте, xvost, Вы писали:
X>До тех пор пока графы и диаграммы помогают понять код — "you'r welcome"! X>Как только пытаются в эти графы запихать ВСЮ программу,и обязать ее модифицировать тоже через графическое представление — fail.
Вообще-то не fail. В телекоме в SDL давно уже многое запихивали и вполне успешно. Другое дело, что чисто графического представления не бывает. Оно всегда смешивается с текстом.
Я когда-то приводил похожий пример для структурного программирования с просьбой обойтись без goto:
Никто так и не смог обойтись. Потому что речь явно идет о детерминированном автомате, поэтому такой алгоритм надо тупо делить на состояния и делать один короткий, но широкий цикл, в начале которого будет один большой switch (или аналогичный переход по таблице переходов автомата). По ссылке примерно так и предложили. Это решение пойдет для любого структурного ЯП, не только ДРАКОНа.
Здравствуйте, vdimas, Вы писали:
V>Я когда-то приводил похожий пример для структурного программирования с просьбой обойтись без goto: V>
V>Никто так и не смог обойтись.
Теорема Бома-Якопини: можно без goto.
Пример: общий цикл с if-ами, в которых идет проверка переменной go_label. Т.е. статические метки заменяются динамическими проверками. Не айс, но формально оператор goto отсутствует. Код писать лениво.
Здравствуйте, samius, Вы писали:
V>>Никто так и не смог обойтись. S>Теорема Бома-Якопини: можно без goto. S>Пример: общий цикл с if-ами, в которых идет проверка переменной go_label.
Это и есть эмуляция goto. Мы в любом случае пропускаем код до нужной метки, только делаем это не за один такт, а за много.
Предложенный мною switch/case для атоматной модели тоже ничем от goto не отличается.
Даже выражения под case так и названы — метки.
?..
