OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Понедельник, 24 Сентябрь, 2018 12:18

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




Начать новую тему Ответить на тему  [ Сообщений: 95 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
 Заголовок сообщения: Re: Моделирование и формализация
СообщениеДобавлено: Суббота, 03 Сентябрь, 2011 19:31 

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

Alexey_Donskoy писал(а):
...
Драконограф писал(а):
А конкретному ЯПЗ, специфичному для некоей "предметки", и будет соответствовать набор средств реализации (допустим, тех же функций АПИ - облечённых в форму ББ-библиотек - так я понимаю?). Часть средств "межпредметные", часть - специфичны для реализации этого ЯПЗ. Ну и технология применения этих средств (в формальном смысле - перевода с ЯПЗ на язык реализации).
Опять конкретика до невразумительности?
"Набор средств для реализации" - это решение ЧАСТНОЙ ЗАДАЧИ предметной области.
Конкретная задача может решаться совсем даже без компьютера - причём тут ББ и АПИ?!

Язык реализации - тоже... Было бы что реализовывать, а язык найдётся! :D
Так оно и было - я согласен. :) Тот же Тьюринг придумал свою "абстрактную машину" (а затем и Колосса как её реализацию) для решения задач криптанализа - которые ранее решались имитаторами-"бомбами" - а ещё раньше карандашом на бумаге. При этом во всех случаях остаётся составляющая в сознании человека, которому интересно решение... :)
Я уже сказал - по опыту решения задач выделяются "межпредметные" средства - "отделим <то-то> от конкретного приложения".


Последний раз редактировалось Владислав Жаринов Суббота, 03 Сентябрь, 2011 19:46, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 03 Сентябрь, 2011 19:36 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
Alexey_Donskoy писал(а):
Info21 писал(а):
Ну, обсуждать значки для электрических схем это сугубый офтоп.
Ну, раз уж тема называется именно "язык программирования", то, вроде бы, офтоп. На первый взгляд.
Только вот почему-то есть достаточно широкий класс задач в разных предметных областях, которые всё же следует отнести к программированию.
Если за программирование системы моделирования на языке электрических схем ещё можно пободаться, то программирование какой-нибудь SCADA на языке FBD и контроллера в её составе на языке LD ( :wink: ) уж однозначно относится к программированию.
В моей практике электроника, математика, ТАУ, программирование и компьютерное моделирование давно уже превратились в какой-то невообразимый коктейль, из которого я не могу убрать ни одну из составляющих.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 03 Сентябрь, 2011 19:52 

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 03 Сентябрь, 2011 20:06 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Alexey_Donskoy писал(а):
Более того, я в данный момент отстаиваю тезис, что универсальный язык вообще невозможен.
Со многим, что Вы написали в этом обсуждении, я согласен, но не с тем, что "универсальный язык невозможен". Мы же общаемся на языке... и даже... иногда... понимаем друг друга. Хотя язык общения далеко не идеален (и постоянно удаляется от идеала), но... тем не менее... он позволяет охватывать огромный спектр задач и проблем. Мало того, трудно (но можно!) подобрать задачи, которые не могли бы быть сформулированы и решены на языке нашего общения. Но и те задачи, которые выпадают... это не проблема самого языка... это проблема моделирования, как такового. Если бы была создана адекватная модель на любом другом языке, то она могла бы быть довольно точно оттранслирована на наш язык. Собственно, язык нашего общения и есть прообраз или пародия на язык унивёрсума... то есть, универсальный язык. Но... необходимо сделать одно существенное замечание... язык должен быть... живым... развивающимся... А это, в свою очередь, означает что в его основе должна быть заложена семантика (смысл). Тогда возможно двойное однозначное/формальное преобразование, как от языковой конструкции на предметную область, так и от предметной области на языковую конструкцию.
Alexey_Donskoy писал(а):
Эффективность, естественно, не в смысле компьютерных ресурсов, а чуть более в общем смысле - от когнитивной эргономики до стоимости решения. ;)
Эффективность, в общем случае, это отношение "выхода" ко "входу"...
Alexey_Donskoy писал(а):
Что можно предложить взамен?
Полагаю, что внимание должно быть сосредоточено не на программировании, а на МОДЕЛИРОВАНИИ.
Пожалуй, как и в любой науке, могла бы быть полезной хотя бы первоначальная классификация, систематизация способов и языков моделирования.
Это невозможно... Попробуйте ответить на простой вопрос, что изучает любая наука... математика, физика, философия... и пр.. Дело не в классификации, поскольку классификация появляется тогда, когда выделены "характерные" признаки... а сами признаки - это уже результат моделирования. Получается, что моделирование первичнее... любой предметной области, то есть, оно само немодельно, неформально.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 04 Сентябрь, 2011 07:50 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1014
Откуда: Россия, Чебоксары
alexus писал(а):
Со многим, что Вы написали в этом обсуждении, я согласен, но не с тем, что "универсальный язык невозможен".
Да, опять погорячился я... склонность к максимам надо как-то преодолевать! ;)
Собственно, ниже как раз и пытался объяснить:

alexus писал(а):
Alexey_Donskoy писал(а):
Эффективность, естественно, не в смысле компьютерных ресурсов, а чуть более в общем смысле - от когнитивной эргономики до стоимости решения. ;)
Эффективность, в общем случае, это отношение "выхода" ко "входу"...
Следует читать: "...в более общем смысле, включая критерии от когнитивной эргономики до стоимости решения..."

Очевидно, что на нашем универсальном языке можно описать любую математическую идею, однако ж простая формула сделает это гораздо эффективнее.
А формула - это язык математики, т.е. пресловутый DSL и есть.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 04 Сентябрь, 2011 08:40 

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 04 Сентябрь, 2011 12:39 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Alexey_Donskoy писал(а):
...
Драконограф писал(а):
А что имеется в виду? Информатизация обозначений по ЕСКД (и неимперативных по ЕСТД)?
Не настолько примитивно-утилитарно, конечно.
Имеются в виду не сами языки-стандарты, и даже не создание инструментов для работы с этими языками, а подходы к созданию этих языков.
Возникли они давно, и прямая их информатизация пока что приводит к не очень привлекательному результату.
Надо обновлять (а то и переписывать заново) подобные стандарты, с учётом нынешних и перспективных задач.
И работа эта по сути - работа с языком представления предметной области, то есть DSL...
А может, для начала выбрать путь, о котором говорил здесь: viewtopic.php?f=62&t=2527&p=60855&hilit=+%D1%80%D0%B0%D1%81%D1%87%D1%91%D1%82%D0%BD%D0%BE#p60855 ? Если коротко - то РДП-документ мыслится как интегрирующий результаты относительно специализированной переработки данных об объектах деятельности в других приложениях (расчётно-логической, специально-оформительской) - а не как заменяющий их. Сама РДП-среда обрабатывает (для чего и содержательно представляет внутри себя) только структуры деятельности (в т.ч. реализуемой [программно-]аппаратно).
    Иначе говоря - изображения сущностей разных "предметок" по-прежнему готовим в актуальных средах (Computer-Aided приложениями разными) - а в документы "редактора процессов" только включаем результаты (вставкой/внедрением/связыванием - что реализовать получилось).
А то получается, если правильно понял, что Вы предлагаете переработку всех "языков техники" для унификации. А это задача, пожалуй, покруче стратегической интеллектуальной инициативы Владимира Даниеловича...


Последний раз редактировалось Владислав Жаринов Воскресенье, 04 Сентябрь, 2011 18:43, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 04 Сентябрь, 2011 18:12 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Alexey_Donskoy писал(а):
alexus писал(а):
Со многим, что Вы написали в этом обсуждении, я согласен, но не с тем, что "универсальный язык невозможен".
Да, опять погорячился я... склонность к максимам надо как-то преодолевать! ;)
Не надо... Это не такое плохое качество, если вдуматься... :)
Alexey_Donskoy писал(а):
Собственно, ниже как раз и пытался объяснить:
Это несколько не то... объяснение, IMHO. Как-то я давал ссылку на "Буквицу" ("Буквица")... собственно, там хорошо виден подход к образованию языка. Аналогично формировались и другие восточные языки, но "ключ" у них либо потерян, либо переведён в разряд "сакрального знания", доступного только посвящённым (в эту версию я не верю).
Суть подхода, который раскрывается в Буквице - системность. Каждая буква обладает собственным (неповторимым) смыслом, и она (буква) является целым. Это целое проецируется одновременно на образ (начертание буквы) и звук (звучание/произношение буквы). Таким образом, единое целое подразделяется на два образа: начертание ("мертвый"/статичный образ) и звук ("живой"/динамичный образ) Из букв складываются слога. Слог не является целым и соответствует некоторой отдельной характеристике самого образа или действия с образом. Слоги, характерные/являющиеся основой для многих образов, образуют корни... Из слогов складывается любое новое слово/новый образ. Поэтому, даже не зная, что обозначает то или иное слово, можно сделать реконструкцию образа, заложенного в слове и... восстановить смысл, скрытый в слове. Собственно... это и изучалось на уроках словесности.
Alexey_Donskoy писал(а):
Очевидно, что на нашем универсальном языке можно описать любую математическую идею, однако ж простая формула сделает это гораздо эффективнее.
А формула - это язык математики, т.е. пресловутый DSL и есть.
Всё дело в том, что язык математики - это просто слабая попытка повторения того, о чём говорилось выше. Любой математический символ ("буква"), имеет смысл: "для каждого/любого", "существует", "принадлежит"... и т.д. Из этих "букв" строятся слоги (утверждения) и слова (выражения), а на их основе теоремы... Но по сравнению с древними языками, язык математики намного слабее (в выразительном плане) и не может (в общем случае), обходиться без других (естественных) языков. В контексте этой мысли, можно утверждать, что язык математики не является каким-то отдельным средством общения, его "специализация" результат не "заточенности" под конкретную предметную область, а... неразвитости. Добавьте к нему (но не бездумно!) новые "буквы" и сможете выражать на мат. языке любые понятия.
Alexey_Donskoy писал(а):
Моё высказывание было в известной мере провокационным, просто для привлечения внимания к теме моделирования... :D
Понятно, но... моделирование (как я понимаю) - это не вопрос для технического форума... поскольку в его основе построение внутренних образов... на этом всё и заканчивается. Разговоры про IDEF, ARIS, UML... и пр. - это от лукавого.


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

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Alexey_Donskoy в viewtopic.php?p=65268#p65268 писал(а):
...
FBD (или, к примеру, DFD) - это не программа, и не данные. Это - язык представления модели в какой-либо предметной области.
С одной и той же моделью можно решать различные задачи.
Скажем, можно преобразовать изображённую систему, изменить способы управления, сгенерировать исполняемую программу для контроллера и т.п.
В частном случае (например, в конкретной системе моделирования) такая схема УЖЕ представляет собой готовую программу. Однако программа эта особого рода - не императивная. Она ближе к парадигме декларативного программирования; причём исполняющая среда может предложить разные способы решения для целого ряда задач.

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

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


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

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1014
Откуда: Россия, Чебоксары
Драконограф писал(а):
Попробую изложить, как понял суть. Вы называете моделью на предметном языке опять же "внешнюю схему" задачи. Но информатизованную - т.е. однозначно преобразуемую в структуру данных, с которой может работать алгоритм "решения различных задач".
Вообще-то, понятие модели шире. Это всего лишь частный случай, который возможен при использовании такого средств механизации творческого труда, как комп ;)
Я согласен с Усовым, когда он говорит про внутренние образы... Но это ведь тоже максима; а в реальной жизни так или иначе всё равно приходится решать задачи, и хотеть механизировать сей труд ;)
Поэтому как отправная точка - имхо, годится.
Может, все методики и от лукавого, но они помогают... когда помогает "комбинаторный подход"...

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

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

В этом смысле, кстати, процесс работы программиста абсолютно ничем не отличается от процесса работы вышеописанного специалиста. Это просто частный случай.

И любой "императив" по сути есть не что иное, как один из возможных DSL для предметной области "алгоритмизация".

Собственно, почему я и встрял в эту тему-то. Потому что мне очень не понравились высказывания Ильи и Info21, претендующие на всеобщность (охват всех взаимоотношений человека с компом), но неявно относящиеся к достаточно узкой и специфической предметной области...

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

Я всё время вспоминаю, как Седов 20 лет назад про это говорил... А воз и ныне там...


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8989
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
В будущем программирование без структурного редактора будет похоже на изучение в школе информатики без доступа к компьютеру.


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

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


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8989
Откуда: Россия, Орёл
Тема действительно сильно расширилась.

Я высказывался по теме DSL в задаче разработки ПО. Как и, насколько я понимаю, Мартин Фаулер.
По теме отношения к идее "давайте меньше программировать на универсальном ЯП, больше на DSL".
Я не высказывался по вопросу тех областей, где нет программирования на ЯП.

Насколько я знаю происхождение термина DSL (тут я могу ошибаться) - он и был введён именно для случая замены УЯП на спец. ЯП (в пределе - декларативный).
А не для случая тех нотаций, которые никогда и не противопоставлялись ЯП.


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

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1014
Откуда: Россия, Чебоксары
Илья Ермаков писал(а):
Я высказывался по теме DSL в задаче разработки ПО...
Ну, в таком контексте тему можно закрывать! :D
Вряд ли кто-то выскажется против озвученного подхода... хотя странно, до сих пор не прозвучали вроде бы ожидаемые возражения SQL-щиков ;)


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

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Alexey_Donskoy писал(а):
Илья Ермаков писал(а):
Я высказывался по теме DSL в задаче разработки ПО...
Ну, в таком контексте тему можно закрывать! :D
Вряд ли кто-то выскажется против озвученного подхода...
Почему нет?.. Подход далеко не оптимальный для тех случаев, когда... каркасы становятся тесноваты для предметной области. Перестройка каркаса - занятие не для слабонервных, а этим придётся заниматься постоянно (чем дальше, тем больше), пока каркас станет настолько неудобным и громоздким, что его проще выкинуть, чем поддерживать. "Чемодан без ручки"... У нас не менее 10-20 soft-фирм (включая аутсорсинг) именно этим и заняты... всё своё очень несвободное время... Думать им некогда... проектирование сводится к заплаткам и подпоркам... каждый видит только свой накренившийся угол... Что же хорошего во всём этом?.. Скучно...
Alexey_Donskoy писал(а):
хотя странно, до сих пор не прозвучали вроде бы ожидаемые возражения SQL-щиков ;)
Получите... :lol: SQL-щикам моделировать надо... им дискуссии о языках... не слишком полезны.


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

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1014
Откуда: Россия, Чебоксары
alexus писал(а):
Подход далеко не оптимальный для тех случаев, когда... каркасы становятся тесноваты для предметной области. Перестройка каркаса - занятие не для слабонервных, а этим придётся заниматься постоянно (чем дальше, тем больше), пока каркас станет настолько неудобным и громоздким, что его проще выкинуть, чем поддерживать.
Ну, тут в теме априори утверждалось, что переделывать каркас, оформленный в виде АПИ, не в пример легче, чем в форме языка. Хотя вот я не улавливаю, в чём вообще между ними принципиальная разница? :D


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

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Илья Ермаков писал(а):
Сергей Прохоренко писал(а):
В будущем программирование без структурного редактора будет похоже на изучение в школе информатики без доступа к компьютеру.


Кстати, аналогия неверная.


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

Илья Ермаков писал(а):
Касательно структурного редактора:
1) Вы делаете интересную вещь, которая наверняка найдёт себе применение.
2) Вы всё-таки не очень хорошо понимаете ряд сторон "живого" программирования.


Ну, это Вам знать неоткуда.

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


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

Цели структурного редактора совершенно иные:
1. Использование структурного редактора должно начинаться еще на стадиях, предшествующих написанию программы, - для разработки архитектуры программы.
2. Структурный редактор должен обеспечивать быструю, бесшовную и безошибочную интеграцию разрабатываемой программы с различными софтверными технологиями.
3. Структурный редактор должен обеспечивать быстрый контекстно-зависимый доступ к разнообразной информации, необходимой при написании программ.
4. Структурный редактор должен обеспечивать безошибочность разрабатываемых программ благодаря техническому ограничению безграмотных решений и халтуры программистов и уменьшению возможности случайных ошибок.
5. Структурный редактор должен поддерживать разрабатываемую программу в порядке, помогающем в дальнейшем легко и безошибочно вносить в нее изменения.

Если всего перечисленного еще нет в обсуждаемых прототипах, то это еще ничего не значит - время еще не пришло.


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8989
Откуда: Россия, Орёл
Отличные цели, но такая постановка задачи невообразимо сложна для одного, интегрированного продукта.
Даже в сфере автоматизации предприятий (где автоматизируется не умственный труд, а более приземлённые процессы) проекты монолитных систем проваливались, а успешные внедрения пошли только тогда, когда признали необходимость автоматизации посредством внедрения ряда слабосвязанных систем. Так появилась концепция SOA, в частности.
Это не значит, что нет системообразующей модели и ядра (а то Alexus сейчас съест меня на второй завтрак :) ), но что каждая сторона автоматизируется с абстрагированием от других, со своей частной детальной моделью - и взаимодействует с другими только через обмен данными.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 05 Сентябрь, 2011 15:59 
Аватара пользователя

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


Да, структурный редактор должен быть не монолитным, а именно интегрированным: модульным, многоуровневым (со своей вкладкой в главном окне и моделью данных на каждом уровне) и с поэтапным развитием и достижением целей, но единым.

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

Есть и аналоги с примитивным функционалом, помогающий понять, как должно выглядеть ядро. Есть и примеры того, как делать не надо (монструозные IDE).


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

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 2846
Откуда: Астрахань
Сергей Прохоренко писал(а):
Илья Ермаков писал(а):
3) Из-за этого Вы переоцениваете область применимости и эффект в производительности труда от структурного редактора.
Эффект будет, но он будет не столь значительным, как Вы предполагаете. Думаю, это будет сдерживать распространение (из-за большей технической сложности) - и надежды на "революцию" не оправдаются. Как это часто бывает с, казалось бы, очень здоровскими техническими идеями. Такой мой прогноз.


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

Цели структурного редактора совершенно иные:
1. Использование структурного редактора должно начинаться еще на стадиях, предшествующих написанию программы, - для разработки архитектуры программы.
2. Структурный редактор должен обеспечивать быструю, бесшовную и безошибочную интеграцию разрабатываемой программы с различными софтверными технологиями.
3. Структурный редактор должен обеспечивать быстрый контекстно-зависимый доступ к разнообразной информации, необходимой при написании программ.
4. Структурный редактор должен обеспечивать безошибочность разрабатываемых программ благодаря техническому ограничению безграмотных решений и халтуры программистов и уменьшению возможности случайных ошибок.
5. Структурный редактор должен поддерживать разрабатываемую программу в порядке, помогающем в дальнейшем легко и безошибочно вносить в нее изменения.

Если всего перечисленного еще нет в обсуждаемых прототипах, то это еще ничего не значит - время еще не пришло.

0. Я согласен с Ермаковым - серебряной пули нет. Однако даже опыт работы самого разработчика в своем семантическом редакторе убеждает, что для начинающего это именно то, что нужно.
Например, он недавно признался, что пробные программы, которые он писал в редакторе, просто сформировали у него структурный стиль написания в Додиезе. И он уже просто не представляет себе, как писать не структурно.
Порефакторив свои же тексты, он не раз говорил, что переделка в структурный вид во многом упрощает код и уменьшает объем текста.
Этой самой структурности мы почти безуспешно пытаемся добиться словесными увещеваниями и карательными мерами на первом-втором курсе... Строишь-строишь, но только отвернешься - пишут "как курица лапой".
А тут вырабатывается рефлекс-привычка, что очень ценно.
1. Пока нам кажется, что для построения хорошей архитектуры нужен инструмент для эволюционного моделирования будущей системы. Хотя учитывая явную модульность в языке - архитектура любых приложений компонентно-модульная.
2. Это самая объемная и самая дурная часть... Тут надо тщательно отбирать, с чем стыковать...
3. Это естественно.
4. Ошибки алгоритмизации никуда не денутся, а лексических и синтаксических - просто нет. Можно еще повысить уровень безошибочности, если внедрить в редактор не только операторы языка, но и паттерны целиком. Но тут - много исследовательской работы...
5. Компонентно-модульный подход уже сам по себе весьма способствует этому. Ну и опять же надо исследовать это вглубь в сочетании с паттернами. Которые, как известно, инкапсулируют изменения.


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

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 2846
Откуда: Астрахань
Илья Ермаков писал(а):
Отличные цели, но такая постановка задачи невообразимо сложна для одного, интегрированного продукта.
Это не значит, что нет системообразующей модели и ядра (а то Alexus сейчас съест меня на второй завтрак :) ), но что каждая сторона автоматизируется с абстрагированием от других, со своей частной детальной моделью - и взаимодействует с другими только через обмен данными.

Вот этого мне пока от пацанов добиться в полной мере не удалось.
Я вижу модель программы - для интерпретатора, и модель программы - для структурного редактора. Да, у них есть нечто общее.
А пацаны пока совсем разделить не могут. Из-за того, что представляют программу и там и там в виде одного и того же семантического дерева. Я тут уже писал о проблемах с архитектурой в редакторе - макароны на вьюхе.
Если удастся мне додавить разделение моделей, то открываются весьма радужные перспективы, например, в реализации разных DSL. Просто пишется подсистема над обеими моделями - и все работает на счет раз... :)


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

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


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

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


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

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