OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 18:23

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




Начать новую тему Ответить на тему  [ Сообщений: 95 ]  На страницу 1, 2, 3, 4, 5  След.
Автор Сообщение
СообщениеДобавлено: Четверг, 01 Сентябрь, 2011 20:39 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Я думаю, книга Мартина Фаулера http://www.ozon.ru/context/detail/id/6967089/
снимает проблему. Просто "изобретаем" DSL и пишем на нем.
Цитата:
В этой книге известный эксперт в области программного обеспечения Мартин Фаулер предоставляет информацию, которая поможет вам определиться, следует ли использовать предметно-ориентированные языки для решения стоящих перед вами задач. Если применение предметно-ориентированных языков окажется оправданным, то вам пригодится вторая часть книги, в которой подробно, на конкретных примерах, описаны технологии, применяемые при создании таких языков.
Методы, описанные в данной книге, могут использоваться в большинстве современных объектно-ориентированных языков программирования. В основном примеры в книге написаны на Java и C#, но в некоторых из них использован Ruby. Все главы по возможности организованы в виде самодостаточных частей, а большинство справочных разделов - в знакомом читателю формате описания шаблонов программирования.
При правильном выборе и применении предметно-ориентированные языки могут существенно упростить сложный код, обеспечить эффективное общение с пользователями, повысить производительность и устранить узкие места разработки. В этой книге известный эксперт в области программного обеспечения Мартин Фаулер предоставляет информацию, которая поможет вам определиться, следует ли использовать предметно-ориентированные языки для решения стоящих перед вами задач. Если применение предметно-ориентированных языков окажется оправданным, то вам пригодится вторая часть книги, в которой подробно, на конкретных примерах, описаны технологии, применяемые при создании таких языков.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 01 Сентябрь, 2011 20:54 
Модератор
Аватара пользователя

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

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


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

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Судя по тому, что у нас получается с редактором, DSL с его помощью можно будет делать на счет раз. Тут проблема в другом - определить семантику самого DSL адекватно кругу решаемых задач.
Потому как для одной задачи писать DSL смысла никакого - слишком хлопотно для одной задачи городить такой огород.


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Я тоже не верю во все эти DSL.

Любой D можно обсуждать на обычном языке + словарь.
Так и тут. Оберон + каркас типов и процедур.


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

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1053
Откуда: Россия, Чебоксары
Info21 писал(а):
Любой D можно обсуждать на обычном языке + словарь.
Так и тут. Оберон + каркас типов и процедур.
Имхо, неоправданное сужение.
Обсудите-ка таким образом D="проект дома":
- с дизайнером;
- с проектировщиком;
- с прорабом...

Или вот, совсем не отходя от программирования - пример DSL для моделирования динамических систем (фактически это Data Flow Diagram):
Код:
1 v 1
2 L (1.5p+1/3.14p3+1.5p2+0.7p+1) (1)

Ну и т.д. и т.п...


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Alexey_Donskoy писал(а):
Info21 писал(а):
Любой D можно обсуждать на обычном языке + словарь.
Так и тут. Оберон + каркас типов и процедур.
Имхо, неоправданное сужение.
Обсудите-ка таким образом D="проект дома":
- с дизайнером;
- с проектировщиком;
- с прорабом...
Уговорили: для прораба придется изменить ключевые слова, взяв однокоренные от одного корня 8)

Alexey_Donskoy писал(а):
Или вот, совсем не отходя от программирования - пример DSL для моделирования динамических систем (фактически это Data Flow Diagram):
Код:
1 v 1
2 L (1.5p+1/3.14p3+1.5p2+0.7p+1) (1)

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

И.Е. уже сказал главное, до сюда относящееся, повторять не буду.


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Библиотечный вариант может быть громоздче по символам, зато прозрачней по проекции на реализацию. Плюс освоить API проще, чем язык, потому что API не содержит исключений относительно правил базового языка. Сравните, что проще вспомнить через год, глядя на программу - DSL или API.

DSL хочут те, кому нужно делать много и похожее. Но чаще программист широкого профиля имеет дело с многим и разным.


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Илья Ермаков писал(а):
DSL хочут те, кому нужно делать много и похожее. Но чаще программист широкого профиля имеет дело с многим и разным.
Можно переформулировать проблему так:

Достаточно ли места для DSL между:
1) Оберон+API+микроязык для данных (особенно если Оберон выучили в школе)
2) фиксированные формы
?


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

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


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

А вспоминать вообще ничего не придется - достаточно будет выбрать нужное из списка/палитры или даже из справки.


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Сергей Прохоренко писал(а):
Думаю, что для случая структурного редактора DSL и API одинаково удобны, так как языковые конструкции можно выбирать из палитры так же легко, как и процедуры.
Но нужно учесть, что структурный редактор -- это довольно сложная вещь.


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

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Info21 писал(а):
Илья Ермаков писал(а):
DSL хочут те, кому нужно делать много и похожее. Но чаще программист широкого профиля имеет дело с многим и разным.
Можно переформулировать проблему так:

Достаточно ли места для DSL между:
1) Оберон+API+микроязык для данных (особенно если Оберон выучили в школе)
2) фиксированные формы
?
Понимается ли DSL как "внешний" язык формализации - подобно FBD в этом сообщении? А формы - это что имеется в виду - интерфейсные, как окна в гуе или документы в 1С?
P.S. Вот чел в этом сообщении говорил, оказывается, примерно о том же (касательно того чего "мы не видим на схеме") - есть разные аспекты представления о деятельности. И надо отделять их в "разные сферы".


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
Думаю, что для случая структурного редактора DSL и API одинаково удобны, так как языковые конструкции можно выбирать из палитры так же легко, как и процедуры.
А вспоминать вообще ничего не придется - достаточно будет выбрать нужное из списка/палитры или даже из справки.


А без структурного редактора? Например, продумывая решение проблемы по пути на работу за рулём? :)


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

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


А без структурного редактора? Например, продумывая решение проблемы по пути на работу за рулём? :)


За рулем лучше сосредоточиться на обстановке, иначе можно попасть в ДТП. :D Я вообще противник частных автомобилей в крупных городах. Автомобилисты отравляют жизнь пешеходам, разбазаривают общественные ресурсы и собственные деньги и мешают развитию общественного транспорта (в т.ч. новых видов транспорта, как PRT). А вот, например, в Сиднее я часто видел в электричках (они же и метро) программистов с ноутбуками. Там, правда, метро поприятнее, чем московское.

В будущем программирование без структурного редактора будет похоже на изучение в школе информатики без доступа к компьютеру.

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


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

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Сергей Прохоренко писал(а):
В будущем программирование без структурного редактора будет похоже на изучение в школе информатики без доступа к компьютеру.

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


Я тут думаю так же. И, кстати, Страуструп еще в 1994 году в книге Дизайн и эволюция С++ писал о том, что профессиональная интегрированная среда программирования должна строиться не вокрух ТЕКСТОВОГО редактора, а вокруг СЕМАНТИКИ конструкций языка.
Вот мы и пытаемся построить систему вокруг семантики конструкций языка. И получается семантический (структурный) редактор.


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

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


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

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


Элементы выражений, библиотечные процедуры, операторы (команды, инструкции), в том числе, многоветочные, паттерны (составные операторы) и таблицы определения типов и переменных. А также более высокоуровневые конструкции (модули, проекты). Может быть, что-то я и упустил.


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

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1053
Откуда: Россия, Чебоксары
Info21 писал(а):
Мой опыт из разряда "и т.д." говорит, что достаточно рассматривать такие выражения как входные данные (типа читать специальным коммандером из текста), и вовсе не обязательно впаивать их в язык.
Естественно, что технически так и делается.
И исходный текст - тоже входные данные для компилятора.

Я немного о другом.
О необходимости DSL для прикладника.

Неужто Вы хотите сказать, что вские САПРы, SCADA, и т.д. и т.п. делать не нужно?
А если уж таки нужно, то упомянутые инструменты несут все признаки и атрибуты полноценной среды программирования, включая ряд поддерживаемых ими языков.

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


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Alexey_Donskoy писал(а):
И исходный текст - тоже входные данные для компилятора.
Я Вас умоляю.

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

Alexey_Donskoy писал(а):
Неужто Вы хотите сказать, что вские САПРы, SCADA, и т.д. и т.п. делать не нужно?
Неужто это можно вычитать из моих соообщений?

Alexey_Donskoy писал(а):
И в таком случае очень важно, чтобы язык этот проектировался тщательно
Ну да. Язык уже спроектирован -- Оберон. Об этом и речь.

А вспомогательные микроязыки будут "гулять" -- И.Е. уже объяснил, почему.


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

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

Тут все высказываются вполне определённо, когда кто-то птыается применить тот же Дракон за пределами чисто алгоритмических задач. И справедливо. Но Вы ж тут то же самое делаете! ИЕ, насколько я понимаю, говорил о вполне конкретных вопросах, относящихся к программированию и языкам программирования.
А у Вас звучит необоснованное расширение области применимости...

Info21 писал(а):
А вспомогательные микроязыки будут "гулять" -- И.Е. уже объяснил, почему.
Какие-такие микроязыки?!

Есть много разных предметных областей, не так ли?
Далеко не все они имеют алгоритм как основной инструмент. Далеко не все они требуют программирования.

Зато все они имеют свой тезаурус. Обычно никак не связанный с программированием.
И поэтому очень странно видеть призывы против языка в пользу API.

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


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Alexey_Donskoy писал(а):
Info21 писал(а):
Alexey_Donskoy писал(а):
Неужто Вы хотите сказать, что вские САПРы, SCADA, и т.д. и т.п. делать не нужно?
Неужто это можно вычитать из моих соообщений?
...
Ну да. Язык уже спроектирован -- Оберон. Об этом и речь.
По-видимому, именно так и звучат Ваши сообщения.
И поэтому я повторяю вопрос - что, чертёж надо на Обероне описывать?
Алексей, мне неохота фехтовать остроумием.
В таких системах обычно развиваются скриптовые языки. Обычные языки программирования с выкрутасами и прибамбасами. Эти языки могли запросто быть комбинациями Оберон+АПИ.


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

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


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

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


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

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