Автор Тема: Модифицированный синтаксис Оберона  (Прочитано 75544 раз)

DIzer

  • Гость
Re: Модифицированный синтаксис Оберона
« Ответ #195 : Март 12, 2012, 03:30:01 pm »
Предлагаю кратко рассмотреть удачные идеи в других языках, которые можно было бы перенести в модифицированный Оберон. Не только то, что относится к синтаксису. К примеру, из таких языков: Ада, Модула3, Zonnon, Objective-C, D, C#, Python

Вот тут еще было похожее обсуждение: http://oberspace.dyndns.org/index.php/topic,26.0.html
А я говорил об этом  Vartovyj

DIzer

  • Гость
Re: Модифицированный синтаксис Оберона
« Ответ #196 : Март 12, 2012, 03:30:57 pm »
А разве протокол не является предметом проектирования?
Он может им являться = а может быть и задан. Вообще давать определение систем произвольной сложности - путем перечисления  допустимых сущностей  и связей -дело неблагодарное по этому мое сообщение следует рассматривать как иллюстративное (да , думаю, что термин проектирование - в моем применении неудачен, в особенности если имеешь дело с инженерами - у них он вызывает рефлекс  аналогичный, тому , который у меня идет от слова моделирование).

Valery Solovey

  • Hero Member
  • *****
  • Сообщений: 509
    • Просмотр профиля
Re: Модифицированный синтаксис Оберона
« Ответ #197 : Март 12, 2012, 04:44:18 pm »
Ну пусть даже и задан. Ведь вообще как таковой он из ничего не взялся? Наверное, был создан в рамках другой системы. Если избавиться от цитаты как контекста и перенести контекст в сам вопрос, то можно спросить у alexus-а так: почему Вы относите протокол к анализу и моделированию, а не к проектированию?

Valery Solovey

  • Hero Member
  • *****
  • Сообщений: 509
    • Просмотр профиля
Re: Модифицированный синтаксис Оберона
« Ответ #198 : Март 12, 2012, 05:45:13 pm »
относите протокол
То есть, создание протокола.

DIzer

  • Гость
Re: Модифицированный синтаксис Оберона
« Ответ #199 : Март 12, 2012, 07:01:06 pm »
Ну пусть даже и задан. Ведь вообще как таковой он из ничего не взялся? Наверное, был создан в рамках другой системы. Если избавиться от цитаты как контекста и перенести контекст в сам вопрос, то можно спросить у alexus-а так: почему Вы относите протокол к анализу и моделированию, а не к проектированию?
И что вас смущает? если вы строите дом из кучи кирпичей и конструкций лежащих на строительной площадке -  какая вам разница какой завод их произвел?
« Последнее редактирование: Март 12, 2012, 07:04:11 pm от DIzer »

alexus

  • Гость
Re: Модифицированный синтаксис Оберона
« Ответ #200 : Март 12, 2012, 07:16:07 pm »
Alexus, чтобы вы предложили сделать в Обероне, чтобы соответствовать вашей концепции интерфейсов?
Дело не в Обероне. Сегодня интерфейсы, как правило, определяются на уровне компонентов или программных модулей. Но более правильно было бы определять их на уровне системы, когда её поделили по уровням. Поскольку Оберон нацелен на создание программ, и никаких системных уровней он не поддерживает, в принципе, то он не может соответствовать "моей" концепции интерфейсов.
Если рассуждать с позиций системы... В соответствии с решаемыми задачами, система разделена на уровни. Каждый вышестоящий уровень общается с нижестоящим (равно, как и наоборот) через интерфейсы. Если мы специфицировали интерфейсы, то можно начинать их реализацию, и язык программирования + среда разработки должны нам показывать, какие интерфейсы и как реализованы (или ещё не реализованы, но распределены по классам/сущностям, или даже не распределены и требуют распределения... то есть, стадия проектирования данного уровня системы ещё не завершена). При этом проектирование может/должно происходить в одной среде разработки, а реализация, на том же Обероне. Тогда среда разработки Оберон (или другого ЯП) должна понимать спецификации, полученные из среды проектирования, помнить версию каждого специфицированного элемента и отличия новой версии от предыдущей, включая источник изменений.
Декларация интерфейсов по структуре/по сути практически не отличается от тех интерфейсов, которые сегодня поддерживаются ЯП. Но я повторю, что дело не в том, как объявлять интерфейсы, а в том, как они образуются. И, следовательно, если в Оберон будет поддержка интерфейсов, то это хорошо, но это не сделает язык более системным, чем он есть сейчас.

DIzer

  • Гость
Re: Модифицированный синтаксис Оберона
« Ответ #201 : Март 12, 2012, 07:35:56 pm »
Дело не в Обероне. Сегодня интерфейсы, как правило, определяются на уровне компонентов или программных модулей. Но более правильно было бы определять их на уровне системы, когда её поделили по уровням. Поскольку Оберон нацелен на создание программ, и никаких системных уровней он не поддерживает, в принципе, то он не может соответствовать "моей" концепции интерфейсов.
Зависит от системы (скажем так, я в основном работаю с системами (несложными архитектурно),   требующими "разработки" предметной области - тут хочешь не хочешь  а приходится разрабатывать ее в терминах наитивного языка, потом отображать на  структуры и алгоритмы, и только после этого переводить получившееся хозяйство на целевой ЯП.),  но если искомую систему можно определить как набор программных компонент четкими связями между ними - почему бы и нет.

alexus

  • Гость
Re: Модифицированный синтаксис Оберона
« Ответ #202 : Март 12, 2012, 07:36:48 pm »
Проектирование - это совсем другое... Проектирование начинается тогда, когда понятна суть будущего продукта... когда найдены основные решения, когда определены базовые протоколы...
А это у меня  входит в проектирование - я трактую его в обобщенном смысле,  и стараюсь использовать для этого этапа  термин "построение системы" как некоторого множества моделей и описания взаимодействия между ними, реакции системы по отношению к внешним параметрам... в более узком смысле, если речь идет об одной или небольшом  числе моделей - о "построении (модификации существующей) модели" , а термин "моделирование"  в этом контексте - стараюсь не использовать.
Построение системы включает в себя 4 этапа:
  • Анализ и моделирование;
  • Проектирование;
  • Планирование;
  • Разработка.
Каждый этап имеет свою специфику и, соответственно, предъявляет разные требования к тем, кто их выполняет. Скажем, моделирует дизайнер, а проектирует конструктор, планирует деятельность - плановик, а выполняет - слесарь. В программировании точно также, хотя часто все стадии выполняет один и тот же человек/одна и та же команда. К сожалению и результаты... бывают далеки от хороших.
Чем выше требования к внешнему виду и эргономике, тем большая потребность в хороших дизайнерах. Если требования к внешнему виду не специфицированы, то... моделирование внешнего вида может быть пропущено. При разработке больших (многоуровневых) технических систем дизайнер должен не только и не столько заниматься внешним видом, сколько компоновкой основных агрегатов, устойчивостью конструкции, основным принципам её функционирования/принципиальной конфигурации системы, если говорить о программных системах...
Проектирование - это более рациональная стадия, где основой является декомпозиция... вплоть до последнего болта... На этой стадии модель разбирается на мельчайшие составные части, для которых, если необходимо, определяются рабочие и максимальные нагрузки, выполняются расчёты и, наконец, выполняются чертежи (в CAD-системе, например). В программных системах при проектировании определяются все внутренние и внешние протоколы, интерфейсы, иерархии классов/наборы сущностей/структуры баз данных, выбираются алгоритмы и пр.
Детально зная, что нам нужно реализовать, примерно определив затраты времени и квалификационные требования, мы можем спланировать работу команды, каждого человека... потребности в тех или иных инструментах, сервисах и пр.
Ну, про стадию реализации все и так знают... :)

DIzer

  • Гость
Re: Модифицированный синтаксис Оберона
« Ответ #203 : Март 12, 2012, 07:52:43 pm »
Построение системы включает в себя 4 этапа:
  • Анализ и моделирование;
  • Проектирование;
  • Планирование;
  • Разработка.
......
Это не вызывает  никаких возражений, я говорю вам, что в ряде случаев эту схему можно упростить (на свой страх и риск) - и не всегда результаты будут плачевны - хотя должен признать, что пренебрежение этапом планирования  достаточно часто  било по моим интересам...

alexus

  • Гость
Re: Модифицированный синтаксис Оберона
« Ответ #204 : Март 12, 2012, 07:54:34 pm »
Моделирование рождается из анализа требований, ресурсных возможностей.
Вы хотели сказать "Модель рождается [...]". Если всё же "моделирование", то не могли бы вы этот момент описать подробнее?
Моделирование, как стадия разработки, рождается из анализа требований. Модель - это результат моделирования. Так что оба варианта правильны, только акценты смещаются, я говорю о моделировании, как о специфической деятельности, Вы переносите акцент на результат.
В качестве примера... Посмотрите на смартфоны. Они относительно недавно появились на рынке и активно развиваются. Фирмы-проектировщики (отметьте, не фирмы-производители!) следят за тем, как воспринимаются те или иные новшества в каждой новой модели смартфона (при этом они отслеживают не только свои модели, но и модели конкурентов). Каждое удачное новшество закрепляется в последующих моделях... Но это только "одна сторона медали", с другой стороны они следят за новыми изделиями: процессорами, контроллерами, разного рода датчиками и сенсорами, памятью, материалами для корпуса, стеклами и пр. Вся эта информация переваривается в головах тех, кто занимается моделированием и... они "выдают на гора" новые модели с улучшенными старыми и совсем новыми возможностями смартфонов. В программировании эти процессы происходят сходным образом... Мы смотрим, насколько удобны в использовании наши программы, что-то дорабатываем в них... и параллельно обсуждаем появление новых инструментов, оцениваем их применимость для наших задач... И в конечном итоге пишем более функциональные и удобные программы с меньшими издержками... (ну, в идеале...) :)

alexus

  • Гость
Re: Модифицированный синтаксис Оберона
« Ответ #205 : Март 12, 2012, 08:06:45 pm »
Ну пусть даже и задан. Ведь вообще как таковой он из ничего не взялся? Наверное, был создан в рамках другой системы. Если избавиться от цитаты как контекста и перенести контекст в сам вопрос, то можно спросить у alexus-а так: почему Вы относите протокол к анализу и моделированию, а не к проектированию?
Протокол может определяться на стадии моделирования, а доопределяться, в виде формальных (однозначных) описаний на стадии проектирования. Приведу аналогию. Дизайнер соединил дом и хозяйственную постройку переходом. Смотрится красиво и удобно: в холодное время года/суток можно перейти из одного здания в другое не надевая тёплую одежду и обувь. Это стадия моделирования. Проектировщики описали (чертежами) сам переход, и в него "втолкнули" инженерные коммуникации: электричество, отопление и т.п. Это стадия проектирования.
Точно также в программной системе, дизайнер определил то, как будут взаимодействовать сущности, не вникая в детали, не расписывая их до байта и бита... А проектировщик потом должен будет сделать полную спецификацию протокола взаимодействия.
Протоколы могут быть внешними. Например, ток подаётся под определённым напряжение, определёной частоты и силы. И все внутренние сущности должны быть ориентированы на работу по этому протоколу. Точно также мы используем при программировании внешний протокол, например, TCP/IP и должны ему следовать.

alexus

  • Гость
Re: Модифицированный синтаксис Оберона
« Ответ #206 : Март 12, 2012, 08:09:00 pm »
Дело не в Обероне. Сегодня интерфейсы, как правило, определяются на уровне компонентов или программных модулей. Но более правильно было бы определять их на уровне системы, когда её поделили по уровням. Поскольку Оберон нацелен на создание программ, и никаких системных уровней он не поддерживает, в принципе, то он не может соответствовать "моей" концепции интерфейсов.
Зависит от системы (скажем так, я в основном работаю с системами (несложными архитектурно),   требующими "разработки" предметной области - тут хочешь не хочешь  а приходится разрабатывать ее в терминах наитивного языка, потом отображать на  структуры и алгоритмы, и только после этого переводить получившееся хозяйство на целевой ЯП.),  но если искомую систему можно определить как набор программных компонент четкими связями между ними - почему бы и нет.
Да, конечно. Для реализации одно/двух-уровневой системы не надо городить протоколы и модели, вполне можно воспользоваться тем, что есть.

alexus

  • Гость
Re: Модифицированный синтаксис Оберона
« Ответ #207 : Март 12, 2012, 08:12:10 pm »
Построение системы включает в себя 4 этапа:
  • Анализ и моделирование;
  • Проектирование;
  • Планирование;
  • Разработка.
......
Это не вызывает  никаких возражений, я говорю вам, что в ряде случаев эту схему можно упростить (на свой страх и риск) - и не всегда результаты будут плачевны - хотя должен признать, что пренебрежение этапом планирования  достаточно часто  било по моим интересам...
Использование стадий разработки - это вопрос времени... и культуры (не этики и эстетики, а культуры работы). Я тоже не всегда прорабатываю все стадии так, как нужно... как правило из-за лени... с верой в авось... :)

DIzer

  • Гость
Re: Модифицированный синтаксис Оберона
« Ответ #208 : Март 12, 2012, 08:22:52 pm »

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

Vartovyj

  • Full Member
  • ***
  • Сообщений: 197
    • Просмотр профиля
Re: Модифицированный синтаксис Оберона
« Ответ #209 : Март 14, 2012, 12:57:16 pm »
Нужен ли CASE OF, если есть IF ELSIF?
DO WHILE вместо REPEAT UNTIL тоже хорошая идея упрощения синтаксиса.