OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 05 Декабрь, 2019 17:18

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 130 ]  На страницу Пред.  1, 2, 3, 4, 5 ... 7  След.
Автор Сообщение
 Заголовок сообщения: Re: Обсуждение проекта PureBuilder
СообщениеДобавлено: Понедельник, 10 Январь, 2011 00:15 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3120
Откуда: Астрахань
Сергей Прохоренко писал(а):
Alexey Veselovsky писал(а):
Какой-то план работ (roadmap) с ориетировочными сроками существует?


У меня - нет. У Валерия Лаптева, который разрабатывает семантический редактор с близкой идеологией - наверное. Насколько я знаю, его студент, участвующий в разработке семантического редактора, должен через несколько лет защитить диплом по этой теме.

Он уже на 4 курсе и принес мне первую рабочую версию - на неделе будем смотреть и копать. Основные особенности - язык программирования минимальный и русский. С учетом изысканий, которые по форме цикла Дейкстры мы тут однажды провели.
Модули есть. Текст набирается сразу конструкциями.
Покажу ему страничку PureBuilder - обсудим.

Единственный пока минус - реализовано на Додиезе в VS 2010/ Просто они сейчас это изучают по одной дисциплине, и у него все " в пальцах". Ничего, потом перепишем.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обсуждение проекта PureBuilder
СообщениеДобавлено: Понедельник, 10 Январь, 2011 00:17 

Зарегистрирован: Пятница, 24 Апрель, 2009 16:28
Сообщения: 531
Откуда: Москва
Илья Ермаков писал(а):
MS Access и мышь - ужасные воспоминания. Я вообще с "обычными" БД работаю редко, но недавно и с Access пришлось, и с MySQL. От SQL и написания SQL-запросов, как и раньше, куча позитивных впечатлений. Access с его тыканием - ужасно.
В MS Access очень хороший построитель запросов. Позитивные впечатления от написания руками получите, когда потребуется быстренько написать 5-10 запросов, в каждом из которых связано штук по 5 таблиц (примитив, на самом деле). Потом понять, что результат (полученные данные) не устраивает и быстренько все переделать.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обсуждение проекта PureBuilder
СообщениеДобавлено: Понедельник, 10 Январь, 2011 00:30 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Валерий Лаптев писал(а):
Сергей Прохоренко писал(а):
Alexey Veselovsky писал(а):
Какой-то план работ (roadmap) с ориетировочными сроками существует?


У меня - нет. У Валерия Лаптева, который разрабатывает семантический редактор с близкой идеологией - наверное. Насколько я знаю, его студент, участвующий в разработке семантического редактора, должен через несколько лет защитить диплом по этой теме.

Он уже на 4 курсе и принес мне первую рабочую версию - на неделе будем смотреть и копать. Основные особенности - язык программирования минимальный и русский. С учетом изысканий, которые по форме цикла Дейкстры мы тут однажды провели.
Модули есть. Текст набирается сразу конструкциями.
Покажу ему страничку PureBuilder - обсудим.

Единственный пока минус - реализовано на Додиезе в VS 2010/ Просто они сейчас это изучают по одной дисциплине, и у него все " в пальцах". Ничего, потом перепишем.


Это просто замечательно! :D

Додиез - может быть, даже и плюс - на нем может получиться привлекательный интерфейс. :wink:


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обсуждение проекта PureBuilder
СообщениеДобавлено: Понедельник, 10 Январь, 2011 01:43 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Цитата:
Лучшим кандадатом на роль встроенной СУБД является Firebird.

Ашипка в слове "кандидатом".
Кстати, а Sqlite рассматривали? Проще, компактнее и наверняка намного надёжнее, чем Firebird.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 10 Январь, 2011 05:11 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Драконограф писал(а):
Сергей Прохоренко писал(а):
Драконограф писал(а):
Пока основной вопрос к понятию "визуальный" в контексте данного проекта.

У UML, Дракона, блок-схем и других графов нет монополии на термин "визуальный"...
Но есть и гораздо более близкая аналогия. Поиск картинок в Гугле по строке "визуальное программирование" дает несколько "неграфовых" систем программирования, в которых программа, как и в PureBuilder, собирается мышкой из "визуальных" блоков, а не набирается на клавиатуре...[/url].

В отличие от графов блоки в этих системах программирования не расползаются по экрану, а располагаются в одну вертикальную линию, как текст программы. Но это не текст...
Тем не менее это некая структура знания о задаче - элементы и связи, атрибутированные сочинителем - только представленная не на текстовой основе.
По поводу систем указанного рода - высказывался здесь о гарантоспособности.
Поясню сказанное в упомянутом сообщении. Понятие "визуальный" мы можем отнести к двум категориям представлений:
    * внешней форме - как инфопрог (и вообще любое изделие) выглядит для пользователя;
    * внутренней форме - как изделие устроено.
"Вижуал-Бейсик" и т.п. среды строятся вокруг первой категории - точнее, её графического представления - и манипулирования при создании элементами/комплексами внешних форм. В общем случае это инжпсихологии не противоречит - если искусственная система для человека, то какие-то видимые формы у неё д.б. Однако кто-то (по-моему, Илья) справедливо говорил - не у каждого отдельного компонента конкретного инфопрога по логике будет видимая внешняя форма - и приходится сопоставлять таким компонентам эти формы искусственно. Посему такое представление будем называть "вижуальным" - дабы отличать от идущего от внутреннего устройства изделия. Кажется, и Вы, Сергей, где-то в дискуссиях были против того, чтобы "кидать код на контролы"? :wink:

А главное - что в этих средах код-то всё равно будет представлен текстом... И здесь переходим к "визуальным" методологиям формализации знаний о задачах - где внутреннему устройству решения (в частном случае - инфопрогизделия) найдена форма представления, отличная от текста, пусть и интендованного.
Почему о некоторых средах я высказывался как об "игровых", а не профессиональных? Потому, что переход от текста к таблицам/графике как основе представления - не самоцель, а средство иначе, нагляднее отразить устройство изделия - как и в случае материальных объектов (визуализируемых по ЕСКД). А архитектура в "игровых" подходах адекватно не отражается. В HiAsm какая-то попытка сделана в стиле IDEF0 ("ICOM-изация" сторон блока) - но это и мало, и не совсем то, что мне бы, например, как независимому от программиста участнику процесса позволило бы понять логику построения изделия. Особенно с учётом сложности принципов, напр. компонентного программирования на тех же Оберон-языках - о чём говорил Илья, допустим, в связи с процедурами-объектами. А причина-то в том, что хотели всё отчуждаемое знание о программном решении задачи "впихнуть" в один тип схем...
В общем, как и в ЕСКД, нужна система взаимосвязанных типов схем разного назначения - каковы они для описания матобъектов, см. напоминание в этом пункте.

И о некоторых аспектах дискуссии по ДРАКОНу. Можно каждый или отдельные типы схем информатических изделий превратить из графового в табличный - но делать это нужно взвешенно, не ухудшая когнитивной эргономики.
Безусловно, "красной нитью" в МФЗ должна проходить возможность декомпозиции - чтобы большое представить системами малых. Для графовой основы я предлагаю областную декомпозицию, введённую здесь, развитую здесь и показанную, в частности, на этом примере. Как сделать эквивалентно, отказываясь от графовой основы - пусть предложат сторонники отказа...


Последний раз редактировалось Владислав Жаринов Понедельник, 10 Январь, 2011 09:16, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 10 Январь, 2011 09:05 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Вот в тему оказалась книжка, вложенная
в это сообщение. Можно отражать импер-структуры как структурограммы - т.е. фактически таблицы специального рода - тем самым достигая предлагаемого Сергеем "устранения соединительных линий" (на то же обращал внимание Илья, скажем, в упомянутых здесь сообщениях).
Поскольку я не "безусловный поклонник" тех или иных средств - ничего неправильного в этом не вижу - только в тех случаях, когда этим линиям (т.е. связям) не приписаны некие значения в рамках данного рода моделей. Иначе связи надо сохранять и искать им какое-то представление в составе таблиц - что не слишком-то эргономично будет... проще тогда от графа не уходить.
Но нужно учесть аспект восприятия - разные структуры следует таблично организовать по-разному (без употребления для этой цели ключевых слов - только конфигурацией и расчерчиванием ячеек). Чтобы не плодить много разновидностей ячеек и ячеечных структур - ограничить типологию представляемых прогтекстовых конструкций. В частности, для импер-структур - свести разнообразие циклов к ПОКА (и развивающему его циклу Дейкстры, конечно). Нужно что-то делать и с исключениями - имея в виду, что это "потенциально досрочные окончания" маршрутной структуры... или такая трактовка (в структурном смысле) требует уточнения?

В принципе было бы интересно видеть "таблично-базированную" среду, наследующую идеи шампур-метода. Нужно только решить опять-таки с табличным представлением силуэтов... Тогда на такое представление в принципе можно перевести и ПК-, и ДМ-схемы из графит-базиса, представленного здесь - да и любые аналогичные.


Последний раз редактировалось Владислав Жаринов Понедельник, 10 Январь, 2011 17:23, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обсуждение проекта PureBuilder
СообщениеДобавлено: Понедельник, 10 Январь, 2011 11:27 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3120
Откуда: Астрахань
Кстати, мы рассматриваем Дракон в качестве основного кандидата для изображения алгоритмов при обучении начинающих. Даже в программе дисциплины явно написали. При развитии обучающей среды ОБЯЗАТЕЛЬНО включим что-нить на тему дракона в нее.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обсуждение проекта PureBuilder
СообщениеДобавлено: Понедельник, 10 Январь, 2011 17:28 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Сергей Прохоренко писал(а):
Peter Almazov писал(а):
Вот маленькая (на фоне остальных) проблема - как должно выглядеть сравнение двух похожих версий программы? Небольшое различие в тексте может приводить к большим различиям в графическом представлении.


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: О целях и средствах формализации
СообщениеДобавлено: Понедельник, 10 Январь, 2011 18:01 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Сергей Прохоренко писал(а):
Кирилл Осенков, разработавший структурный редактор C#, идеологически похожий на PureBuilder, - сотрудник Microsoft (правда, структурный редактор C# - его личная инициатива). Значит, внутри "индустриальных китов" есть люди, которые понимают, что структурный редактор необходим. И не пройдет и ...дцати лет, как он станет составной частью Visual Studio. Но больно уж долго "индустриальные киты" запрягают - выжидают, пока приносят прибыль прежние разработки.
И как составная часть он войдёт неизвестно в каком виде... а люди, конечно, везде есть :)
Сергей Прохоренко писал(а):
Драконограф писал(а):
Для кого делается эта среда? Если "для программистов" - то тут уже поднаторели "индустриальные киты" типа MS, известные "магнаты сложности" (часто "избыточной"). Нужно ли их "переплёвывать"? А если от этого уходить, то вылезает главное - есть ББ с его концепцией "текст как интерфейс" - которой трудно противопоставть что-то


Почему концепции "текст как интерфейс" трудно что-то противопоставить? Вовсе нет. Вот Вы же противопоставляете Дракон!
Только опубликовал работы по "адаптивизации" здеся - и пожалуйста, пример на "избирательное цитирование"... правда, у Вас это, наверное, невольно получилось - в отличие от упомянутого там автора :)

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

    И вообще что спорить - когда, возможно, писать нормальный структурный редактор в ББ нужно будет в итоге - с учётом сказанного в этом соообщении. Как говорится, "не плюй в колодец - пригодится воды напиться" :)
Более того, я считаю (и говорил об этом), что в среде разработки и документирования д.б. возможность показать/редактировать описание и графитно, и текстово - как раз в расчёте на разные типы людей. Для второго случая как раз пригодна "расцветка" формального текста - возможно, как раз такая, как Вы предлагаете. И надо иметь в виду (для декомпозиции в частности), что текст (немаршрутный в смысле классификации частных знаний здесь) м.б. и неформальным - и такой тоже д.б. допустим как "родной" диалект структурных конструкций (см. пример качественного определения для импер-языка).

Сергей Прохоренко в viewtopic.php?p=57231#p57231 писал(а):
Целевых групп PureBuilder несколько:
  • те, кто обучаются программированию...
  • те специалисты, которые не являются программистами, но могут пользоваться инструментами с уровнем сложности MS Office, например, могут создавать базы данных и писать макросы в MS Access для автоматизации своей работы...
  • профессиональные программисты, которым нужен инструмент, многократно повышающий производительность их труда...
И ещё раз - документ среды должен отражать не только текст программы - а вообще поддающееся формализации знание о решаемой задаче (конечно, это частное назначение - содержанием документа м.б. и комплекс задач, и просто комплекс сведений о "предметке", выбранных сочинителем). Т.е. он создаётся всеми участниками триады "предметник-аналитик-программист". И его содержание - это прежде всего "паспорт" задачи (её "внешняя схема"). А уж далее идёт "нейтральная" - модель, пригодная для трансляции (но прежде - для инжпроработки) - и на соответствующем языковом семействе. Причём до программирования очередь может дойти далеко не сразу - "нейтральная" формализация нужна и для инженерного анализа деятельности... А когда дойдёт - то должна получиться система взаимодействующих процессов, реализованных как инфопрог[и] и как инструкция оператору по работе с исполнителем этого инфопрога - как в этом примере.

А среди выделенных Вами целевых групп вижу снова программистов - вторая относится к "утилитаристам" (создателям изделий "для себя"), что сути дела не меняет. Если позиционировать среду как инструмент, поддерживающий гарантоспособный труд (эффективный и надёжный) - то этого недостаточно.


Последний раз редактировалось Владислав Жаринов Вторник, 11 Январь, 2011 07:13, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обсуждение проекта PureBuilder
СообщениеДобавлено: Понедельник, 10 Январь, 2011 19:45 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Валерий Лаптев писал(а):
Кстати, мы рассматриваем Дракон в качестве основного кандидата для изображения алгоритмов при обучении начинающих. Даже в программе дисциплины явно написали. При развитии обучающей среды ОБЯЗАТЕЛЬНО включим что-нить на тему дракона в нее.
А как Вы относитесь к табличному представлению структуры - типа структурограмм?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обсуждение проекта PureBuilder
СообщениеДобавлено: Понедельник, 10 Январь, 2011 20:38 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Geniepro писал(а):
Цитата:
Лучшим кандадатом на роль встроенной СУБД является Firebird.

Ашипка в слове "кандидатом".
Кстати, а Sqlite рассматривали? Проще, компактнее и наверняка намного надёжнее, чем Firebird.


Спасибо, исправил.

Рассматривал. И мы с Вами это уже обсуждали. Firebird победил. :D Подробности уже не помню. Помню только, что Firebird мгновенно восстанавливается после машинных сбоев. Но в любом случае выбор за Валерием Лаптевым - ему решать.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обсуждение проекта PureBuilder
СообщениеДобавлено: Понедельник, 10 Январь, 2011 21:31 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Драконограф писал(а):
Вы предлагаете как раз уходить - т.е. остаться в текстовом представлении (пусть с "расцветкой" синтаксиса) - и тут общее поле с ББ. Это я и имел в виду.
ДРАКОН же (а точнее - шампур-метод и графит-метод как его развитие) находятся в другом поле - где мы уходим от чисто текстового представления знаний к "графитному".


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 11 Январь, 2011 06:27 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Сергей Прохоренко писал(а):
Валерий Лаптев писал(а):
...Единственный пока минус - реализовано на Додиезе в VS 2010/ Просто они сейчас это изучают по одной дисциплине, и у него все " в пальцах". Ничего, потом перепишем.
Это просто замечательно! :D
Додиез - может быть, даже и плюс - на нем может получиться привлекательный интерфейс. :wink:
А как работать будет - не получится ли, как при эксплуатации изделия, описываемой, в частности, в этой теме - исправления за исправлениями? Да ещё и "хитрые" относительно по-человечески естественного представления о работе со схемами особенности выполнения отдельных действий. И в чём причина такого положения дел на взгляд профессионалов? В языке (Объектный Паскаль) или в среде (Дельфи) или в программировании? Удастся ли избежать этого в обсуждаемых здесь изделиях - т.е. можно ли будет их просто совершенствовать, чтобы не приводило к появлению "фич" и "багов" - исправление которых, ессно, отвлекает от целевых изменений изделия? Не лучше ли писать на Оберон-семействе?


Последний раз редактировалось Владислав Жаринов Вторник, 11 Январь, 2011 07:14, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Ещё раз о целях и средствах :)
СообщениеДобавлено: Вторник, 11 Январь, 2011 06:34 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Сергей Прохоренко писал(а):
Драконограф писал(а):
Вы предлагаете как раз уходить - т.е. остаться в текстовом представлении (пусть с "расцветкой" синтаксиса) - и тут общее поле с ББ. Это я и имел в виду.
ДРАКОН же (а точнее - шампур-метод и графит-метод как его развитие) находятся в другом поле - где мы уходим от чисто текстового представления знаний к "графитному".


PureBuilder - это вовсе не "расцветка" синтаксиса. PureBuilder имеет не больше текстового представления, чем Дракон. Просто Дракон - это двумерная блок-схема, а PureBuilder - одномерная - вытянутая только в вертикальном направлении. Связи между блоками обозначаются в Драконе линиями, а в PureBuilder - вложенностью блоков, ветвями многоветочных конструкций, модульностью, передаваемыми параметрами и т.п. Разнообразие инструментария в PureBuilder позволяет каждый объект разрабатываемой программы изобразить наиболее подходящим способом, естественнее и проще для восприятия. Там, где это целесообразно, в PureBuilder используются графы, например, для отображения связей между модулями.
Ну, так. Физически связи как обозначаться могут? Большинство употреблённых Вами понятий ведь логические.
Вот есть следование "блоков" (наверное, правильно заимствовать из РБНФ-технологии описания термин SeqStatement). В шампур-методе оно показывается связкой блочных вершин звеньями вертикали; какими средствами в документе Вашей среды его будем обозначать? И есть ветвление - какие у Вас средства изображения "многоветочных конструкций"?
Модульность - её саму надо выразить в документе; я применительно к Оберон-подобным языкам предлагаю на графовой основе ПК-язык, практическое употребление можно найти на листе 5 в этом примере - какими средствами предлагаете Вы?
Передача параметров - тоже логический механизм. Физику я предлагаю отобразить целостно в ДМ-языке - через совмещение применительно к вызову процедуры формальных и фактических параметров - пример в ДМ-схеме на этой картинке.
Вложенность блоков - что имеется в виду? Текстуальное вложение процедур деятельности (в частном случае - программных)? Возможно его визуализировать средствами АТ-языка, предварительно определяемого здесь - примеры см. Листинги 73...75 здесь. Вопрос опять тот же...
Ещё один более общий вопрос - раз структуру импер-маршрутов Вы предлагаете компоновать одномерно - т.е. придать ей лиоформу в смысле определения в конце этого подпункта (как я понимаю, это касается и деклар-отношений, и актив-связей - буде Вы решите всё-таки и этот неотъемлемый компонент частного знания о задаче дать возможность фиксировать в своей среде, а не где-то отдельно) - какими средствами предлагается укладывать нелинейные структуры на плоскости документа без пересечений? С чисто текстовым представлением (без накладки структурографирующих элементов в виде тех же межстрочных скобок) более-менее понятно - но если Ваша среда поддерживает не только его - тогда как? Уже оструктуривание текста м.б. проблематичным - если маршруты пересекаются. Паронджанов предложил силуэтизацию для графов (маршрутных) - что у Вас?

Тут может возникнуть вопрос - а что, не ограничиться ли в среде тем, что как-нибудь зафиксировать содержание текста программы, дав средства изображения его отдельных составляющих "наиболее подходящим образом" - и хватит с юзеров? :wink: Почему так не пойдёт - объяснял уже в конце предыдущего поста. Если моего слова как "предметника" недостаточно - послушаем создателя автоматного программирования (курсив авторов):
Поликарпова, Шалыто на с. 8 писал(а):
Отметим, что термин "программирование" в этой книге употребляется в широком смысле. Как процесс он означает то же, что и "разработка", "создание" программного обеспечения. Как разновидность (в словосочетаниях "автоматное программирование", "объектно-ориентированное программирование" и т.п.) он является синонимом терминов "метод", "подход", "парадигма". Для обозначения программирования в узком смысле (написания понятного компьютеру кода) в книге используется термин "реализация".
Речь идёт о книге, анонсированной в этом сообщении. В дискуссионных целях, наверное, дам выдержки из неё - там же.
Вот "программирование в широком смысле" по Шалыто - это то же, что "формализация знаний о задаче до уровня командных моделей с программной составляющей" в смысле иерархии двуединого процесса моделирования/формализации, обсуждаемой в этом пункте. Далее в книге, кстати, обсуждается, как зафиксировать в спецификациях решения задачи и актив-знание (об исполнителе) - в рамках целостной с импер- и деклар-знаниями модели решения.

Итак, в ходе моделирования/формализации вся ролевая триада "предметник-аналитик-программист" (а не только третий её участник) накапливает постепенно информатизуемое знание о задаче (а заодно и о каких-то других, и обо всей "предметке"). Часть этого знания обобщённая - её вообще не всю информатизуют - просто дают в "паспорте" задачи текстом (ограниченным, математическим). Понятие паспорта обсуждается в этом подразделе.
И надо предоставить возможность участникам триады (это м.б. как люди, так и коллективы - лишь в частных случаях один человек совмещает какие-то две или все три роли) создавать весь паспорт задачи в одной среде от начала до конца. Это элементарное требование экономики - что получается, если ему не следовать, показано на примере разбора одной существующей среды описания в п/р 6.2 документа, вложенного в это сообщение.
    Не последнюю роль в паспорте играют спецификации техтребований - для той же проверки моделей - на соответствующих языках (*TL-формулы, never-процессы).

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

P.S. Неточно дал ссылки на АТ-язык и примеры - на конференции в сообщениях только начальные варианты, а рабочие - в Драконографике, где возможности для форматирования шире :) Исправлено выше в сообщении.


Последний раз редактировалось Владислав Жаринов Вторник, 11 Январь, 2011 15:02, всего редактировалось 4 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ещё раз о целях и средствах :)
СообщениеДобавлено: Вторник, 11 Январь, 2011 08:22 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
В отношении всё того же - можно почитать публикации в этом соообщении. Есть над чем подумать... и проструктурировать "предметку" PureBuilder.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обсуждение проекта PureBuilder
СообщениеДобавлено: Вторник, 11 Январь, 2011 09:37 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Валерий Лаптев писал(а):
...Основные особенности - язык программирования минимальный и русский. С учетом изысканий, которые по форме цикла Дейкстры мы тут однажды провели.
А что за изыскания?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обсуждение проекта PureBuilder
СообщениеДобавлено: Вторник, 11 Январь, 2011 11:16 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Александр Ильин писал(а):
Цитата:
PureBuilder должен, оставаясь по-возможности лаконичным, наглядными средствами поддерживать разнообразные (но не любые существующие) парадигмы программирования:
    Автоматное программирование в форме SWITCH-технологии
    Функциональное программирование
    Логическое программирование
    Процедурное программирование
    Структурное программирование
    Объектно-ориентированное программирование
    Обобщенное программирование
    Компонентно-ориентированное программирование
    Параллельное и распределенное программирование
Предлагаю скорректировать название проекта: PureeMasher.
Тут стоит учесть, что некоторые парадигмы, наверное, плохо сочетаемы (если не взаимоисключающие) - а некоторые, напротив, хорошо объединяются (где-то однорангово, где-то иерархически).
Как обещал в этом сообщении, вложил выдержку из самой работы по автоматному программированию в это сообщение. Актуальна, очевидно, будет увязка с описанным ещё и графит-деклар-моделей. Интересно, было ли это у Шалыто... знатоки SWITCH-методологии, ау-у... :)


Последний раз редактировалось Владислав Жаринов Вторник, 11 Январь, 2011 11:18, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обсуждение проекта PureBuilder
СообщениеДобавлено: Вторник, 11 Январь, 2011 11:18 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Есть у меня изначально какое-то не понимание фундаментальной цели....

Ну зацепимся за такое, к примеру:
Сергей Прохоренко писал(а):
Связи между блоками обозначаются в Драконе линиями, а в PureBuilder - вложенностью блоков, ветвями многоветочных конструкций, модульностью, передаваемыми параметрами и т.п.
Бог с ним с Драконом (на минутку хотя бы)
Но с какой такой радости, генерируя семантическое дерево (почему не ДАГ?) программы, мы считаем наиболее удобным способом вводить его в "линейном виде с нужными отступами" :?:
Кто не дает вводить дерево - именно как дерево ???
Ну типа: узел дерева IF - от него отходят две ветки. Которые в свою очередь... ну Вы в курсе.

Представьте себе "инопланетянина", в достаточной степени познавшего Человеческую культуру, и попробуйте ему втолковать Величие Текста с Отступами :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обсуждение проекта PureBuilder
СообщениеДобавлено: Вторник, 11 Январь, 2011 11:28 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Galkov писал(а):
Есть у меня изначально какое-то не понимание фундаментальной цели....

Ну зацепимся за такое, к примеру:
Сергей Прохоренко писал(а):
Связи между блоками обозначаются в Драконе линиями, а в PureBuilder - вложенностью блоков, ветвями многоветочных конструкций, модульностью, передаваемыми параметрами и т.п.
Бог с ним с Драконом (на минутку хотя бы)...
Да, вот в том-то и штука - если и отвлечёмся от граф-импер-языка - всё равно есть вопросы к логике и физике модели как таковым - и Ваши, и поставленные в этом сообщении... а может, и ещё какие...
Среди "ещё каких" - обеспечение ссылки на разные описания одного и того же по имени.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обсуждение проекта PureBuilder
СообщениеДобавлено: Вторник, 11 Январь, 2011 12:38 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Galkov писал(а):
Представьте себе "инопланетянина", в достаточной степени познавшего Человеческую культуру, и попробуйте ему втолковать Величие Текста с Отступами :)

Chris Okasaki, "In praise of mandatory indentation for novice programmers"


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 130 ]  На страницу Пред.  1, 2, 3, 4, 5 ... 7  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB