OberonCore https://forum.oberoncore.ru/ |
|
Оберон и проектирование систем https://forum.oberoncore.ru/viewtopic.php?f=86&t=3570 |
Страница 1 из 3 |
Автор: | Илья Ермаков [ Понедельник, 19 Сентябрь, 2011 11:52 ] |
Заголовок сообщения: | Оберон и проектирование систем |
Тема отделена отсюда: viewtopic.php?f=78&t=3463 alexus писал(а): С Oberon та же проблема. Он является прямым продолжением Модулы... и по-прежнему является процедурно-модульным языком. Объекты в нём - это "подарок бедным"... Понимания того, что язык разработки должен объединять и язык моделирования, и язык проектирования, и язык программирования... не наблюдается. На самом деле объекты в нём - не "подарок бедным", а экстракт МЕХАНИЗМОВ ООП. Т.е. то, что нужно и достаточно для реализации разных вариантов. Это соответствует идеологии языка, который задуман как удобная абстракция машины, без претензий на удовлетворение каких-либо особых потребностей кого-то из прикладников. Цель - поднять абстракции и надёжность языка максимально, насколько это возможно без потери исходных возможностей оборудования. Кроме того, на каждом витке развития от Модулы до КП и О7 Оберон остаётся бесспорным рабочим инструментом, в который не просочилось ничего спорного и экспериментального, что бы потом висело бесполезным грузом, кандидатом на исключение (а ведь хрен исключишь, из промышленного языка-то). Так что: Цитата: Понимания того, что язык разработки должен объединять и язык моделирования, и язык проектирования, и язык программирования... не наблюдается. ДОЛЖЕН - в будущем. Когда, наконец, разберёмся с моделированием, настолько ясно, насколько Вирт разобрался с программированием и чисто-программным проектированием. Любые эксперименты можно делать поверх языка, библиотечно или инструментом типа CASE. |
Автор: | Владислав Жаринов [ Понедельник, 19 Сентябрь, 2011 13:05 ] |
Заголовок сообщения: | Re: ДРАКОН - схемы в работе, образовании и жизни |
alexus писал(а): ... Она и динамичной может быть... Мне, скажем, вера в когнитивную эффективность техноязыка не помешала согласиться с тем, что ради достижения изоморфии с дракон-силуэтом не нужно тащить в маршрутный подъязык текстового инфор-языка явные БП, если их там не должно быть... А в результате была выявлена изоморфная силуэту запись маршрутов без явных БП по шампур-методу (через цикл Дейкстры). Правда, здесь тоже не без веры... только уже Фёдору Васильевичу и его единомышленникам... Да, я согласен с Вами. Возможно, так и должно быть... без веры ничего не получится, а вера антипод сомнениям и размышлениям. alexus писал(а): ... Как раз хотел прояснения Вашей позиции насчёт Оберон-семейства... Вы так оцениваете на основании знакомства с сутью механизмов - хотя бы по публикации Свердлова? Или по материалам этой темы?С Oberon та же проблема. Он является прямым продолжением Модулы... и по-прежнему является процедурно-модульным языком. Объекты в нём - это "подарок бедным"... alexus писал(а): ... Пока не ставится задача конкретной гибридизации - так и будет, полагаю... Как только сосредотачиваемся на изоморфии конкретному языку/набору языков - выявляется, что надо от новой формы записи. И ведь у "автоматчиков" то же было - подошли они со своей парадигмой к юмлю - и появились "прецизионные", "исполнимые" его определения... не знаю только, избавило ли это его вполне от тех свойств, которые Вы отметили... Понимания того, что язык разработки должен объединять и язык моделирования, и язык проектирования, и язык программирования... не наблюдается. Фактически остаются паллиативные решения типа UML... куцые, мультикорневые... бестолковые (если кратко). ... Кстати, если подумать - то объединение тоже можно ведь сначала проводить для текстового базиса. Скажем - Оберон и Promela... А дальше - думать над визуализацией комплекса... Да, язык проектирования - что это в Вашем понимании? Чем отличается? |
Автор: | alexus [ Понедельник, 19 Сентябрь, 2011 15:44 ] |
Заголовок сообщения: | Re: ДРАКОН - схемы в работе, образовании и жизни |
Илья Ермаков писал(а): alexus писал(а): С Oberon та же проблема. Он является прямым продолжением Модулы... и по-прежнему является процедурно-модульным языком. Объекты в нём - это "подарок бедным"... Понимания того, что язык разработки должен объединять и язык моделирования, и язык проектирования, и язык программирования... не наблюдается. На самом деле объекты в нём - не "подарок бедным", а экстракт МЕХАНИЗМОВ ООП. Т.е. то, что нужно и достаточно для реализации разных вариантов. Это соответствует идеологии языка, который задуман как удобная абстракция машины, без претензий на удовлетворение каких-либо особых потребностей кого-то из прикладников. Цель - поднять абстракции и надёжность языка максимально, насколько это возможно без потери исходных возможностей оборудования.Для меня ООП - это средство моделирования/проектирования систем. И здесь, сделанных Н. Виртом в Обероне расширений, совершенно недостаточно. (Речь идёт, именно, о получении высококачественных абстракций/моделей!) В этом и проблема, что Н. Вирт, как впрочем и адепты ООП, не пытается рассматривать ООП, как средство моделирования систем (а для написания программ ООП, как правило, избыточен). Илья Ермаков писал(а): Так что: При чём здесь эксперименты?.. Попробуйте с помощью библиотек смоделировать/спроектировать систему... Н. Вирт был прекрасным алгоритмистом... и остаётся им... И его "довесок" в виде ООП - это не потребность Оберон, а нечто вроде... "Хотите ООП?.. Нате вам... только отвяжитесь"... Что можно сделать нового с помощью ООП в Оберон, чего бы нельзя было сделать без него [без ООП]?..
Цитата: Понимания того, что язык разработки должен объединять и язык моделирования, и язык проектирования, и язык программирования... не наблюдается. ДОЛЖЕН - в будущем. Когда, наконец, разберёмся с моделированием, настолько ясно, насколько Вирт разобрался с программированием и чисто-программным проектированием.Любые эксперименты можно делать поверх языка, библиотечно или инструментом типа CASE. |
Автор: | Madzi [ Понедельник, 19 Сентябрь, 2011 16:00 ] |
Заголовок сообщения: | Re: ДРАКОН - схемы в работе, образовании и жизни |
alexus писал(а): При чём здесь эксперименты?.. Попробуйте с помощью библиотек смоделировать/спроектировать систему... Н. Вирт был прекрасным алгоритмистом... и остаётся им... И его "довесок" в виде ООП - это не потребность Оберон, а нечто вроде... "Хотите ООП?.. Нате вам... только отвяжитесь"... Что можно сделать нового с помощью ООП в Оберон, чего бы нельзя было сделать без него [без ООП]?.. А что вы скажете про Active Oberon. Где присутствует определённая сущность OBJECT, которая обладает конретными свойствами и даже своей нитью выполнения? |
Автор: | albobin [ Понедельник, 19 Сентябрь, 2011 16:56 ] |
Заголовок сообщения: | Re: ДРАКОН - схемы в работе, образовании и жизни |
Компилятор Оберона генерит код для целевого процессора. Компилятор ЯзыкаМоделированияСистем генерит Оберон-код. Дело за малым - Report ЯзыкаМоделированияСистем. |
Автор: | Владислав Жаринов [ Понедельник, 19 Сентябрь, 2011 17:06 ] |
Заголовок сообщения: | Система языков формализации |
М.б. не совсем так - язык проектирования (допустим, визуальный на базе шампур-метода - чтобы не отклоняться от топика сильно ) генерит код (исхтекст) и на языке программирования (Оберон) - и на языке моделирования (Promela)? Правда, поставленный Вами вопрос (об определении проект-языка или хотя бы его концепции - включая соотношение с другими языками триады) это не снимает... Но не всё сразу, наверное - для этого и данная линия обсуждения (которую, вероятно, со временем надо отделить будет )... |
Автор: | Madzi [ Понедельник, 19 Сентябрь, 2011 17:13 ] |
Заголовок сообщения: | Re: ДРАКОН - схемы в работе, образовании и жизни |
albobin писал(а): Компилятор Оберона генерит код для целевого процессора. Компилятор ЯзыкаМоделированияСистем генерит Оберон-код. Дело за малым - Report ЯзыкаМоделированияСистем. Советую ознакомится с "Composita" - язык моделирования систем, надстройка над Active Oberon. |
Автор: | Владислав Жаринов [ Понедельник, 19 Сентябрь, 2011 17:27 ] |
Заголовок сообщения: | Языки моделирования в работе, образовании и жизни :) |
Интересно... кто разбирается - у этого языка те же цели и задачи, что у Promela (исходя из этого описания второго, скажем)? |
Автор: | alexus [ Понедельник, 19 Сентябрь, 2011 17:30 ] |
Заголовок сообщения: | Re: ДРАКОН - схемы в работе, образовании и жизни |
Драконограф писал(а): alexus писал(а): Да, я согласен с Вами. Возможно, так и должно быть... без веры ничего не получится, а вера антипод сомнениям и размышлениям. Она и динамичной может быть...Драконограф писал(а): Мне, скажем, вера в когнитивную эффективность техноязыка не помешала согласиться с тем, что ради достижения изоморфии с дракон-силуэтом не нужно тащить в маршрутный подъязык текстового инфор-языка явные БП, если их там не должно быть... А в результате была выявлена изоморфная силуэту запись маршрутов без явных БП по шампур-методу (через цикл Дейкстры). Правда, здесь тоже не без веры... только уже Фёдору Васильевичу и его единомышленникам... Не могу комментировать, поскольку info21 в чёрном списке... не читаю.Драконограф писал(а): alexus писал(а): С Oberon та же проблема. Он является прямым продолжением Модулы... и по-прежнему является процедурно-модульным языком. Объекты в нём - это "подарок бедным"... Как раз хотел прояснения Вашей позиции насчёт Оберон-семейства... Вы так оцениваете на основании знакомства с сутью механизмов - хотя бы по публикации Свердлова?Вложение: (стр. 107) Речь идёт о разработке программ... Применительно к программам все правильно, хотя появляются вопросы о том, что такое "объектная манера мышления" и зачем она нужна?..Драконограф писал(а): Или по материалам этой темы? Здесь обсуждаются частные вопросы... (после просмотра 2-х страниц)...Драконограф писал(а): alexus писал(а): Понимания того, что язык разработки должен объединять и язык моделирования, и язык проектирования, и язык программирования... не наблюдается. Фактически остаются паллиативные решения типа UML... куцые, мультикорневые... бестолковые (если кратко). Пока не ставится задача конкретной гибридизации - так и будет, полагаю... Как только сосредотачиваемся на изоморфии конкретному языку/набору языков - выявляется, что надо от новой формы записи. И ведь у "автоматчиков" то же было - подошли они со своей парадигмой к юмлю - и появились "прецизионные", "исполнимые" его определения... не знаю только, избавило ли это его вполне от тех свойств, которые Вы отметили... ... Кстати, если подумать - то объединение тоже можно ведь сначала проводить для текстового базиса. Скажем - Оберон и Promela... А дальше - думать над визуализацией комплекса... Да, язык проектирования - что это в Вашем понимании? Чем отличается? |
Автор: | alexus [ Понедельник, 19 Сентябрь, 2011 17:31 ] |
Заголовок сообщения: | Re: ДРАКОН - схемы в работе, образовании и жизни |
Madzi писал(а): alexus писал(а): При чём здесь эксперименты?.. Попробуйте с помощью библиотек смоделировать/спроектировать систему... Н. Вирт был прекрасным алгоритмистом... и остаётся им... И его "довесок" в виде ООП - это не потребность Оберон, а нечто вроде... "Хотите ООП?.. Нате вам... только отвяжитесь"... Что можно сделать нового с помощью ООП в Оберон, чего бы нельзя было сделать без него [без ООП]?.. А что вы скажете про Active Oberon. Где присутствует определённая сущность OBJECT, которая обладает конретными свойствами и даже своей нитью выполнения? |
Автор: | albobin [ Понедельник, 19 Сентябрь, 2011 18:24 ] |
Заголовок сообщения: | Re: ДРАКОН - схемы в работе, образовании и жизни |
Madzi писал(а): albobin писал(а): Компилятор Оберона генерит код для целевого процессора. Компилятор ЯзыкаМоделированияСистем генерит Оберон-код. Дело за малым - Report ЯзыкаМоделированияСистем. Советую ознакомится с "Composita" - язык моделирования систем, надстройка над Active Oberon. Это всё не то - это всё вариации Оберона Вирта. Интересно узнать, чего же это такое - "совершенно недостаточно" из недавнего поста. Расширяемые структуры данных, процедурные типы, модули ... что ещё надо? или что-то совсем иное? Хотелось бы узнать, а что будет "совершенно достаточно"? |
Автор: | Владислав Жаринов [ Понедельник, 19 Сентябрь, 2011 18:27 ] |
Заголовок сообщения: | Re: ДРАКОН - схемы в работе, образовании и жизни |
alexus писал(а): ... Жаль... если отталкивает частая категоричность суждений - так она тоже не "статична". Скажем, по тому же техноязыку - отношение в этом посте оценивалось как негативное. Однако когда выяснилось, что метод позволяет выразить на языке и иной подход к программированию, чем предложен создателем техноязыка - в этом посте никакого негатива не обнаружилось... Впрочем, это м.б. личное - и не могу настаивать на изменении отношения...Драконограф писал(а): Мне, скажем, вера в когнитивную эффективность техноязыка не помешала согласиться с тем, что ради достижения изоморфии с дракон-силуэтом не нужно тащить в маршрутный подъязык текстового инфор-языка явные БП, если их там не должно быть... А в результате была выявлена изоморфная силуэту запись маршрутов без явных БП по шампур-методу (через цикл Дейкстры). Правда, здесь тоже не без веры... только уже Фёдору Васильевичу и его единомышленникам... Не могу комментировать, поскольку info21 в чёрном списке... не читаю.Скажем так - Илье Евгеньевичу и его единомышленникам... |
Автор: | Владислав Жаринов [ Понедельник, 19 Сентябрь, 2011 18:43 ] |
Заголовок сообщения: | Re: ДРАКОН - схемы в работе, образовании и жизни |
albobin писал(а): ... Мне кажется, вы о разных "схемах" говорите - Madzi (как и alexus) - о "внешней", Вы - о "нейтральной". В смысле, описанном в этом посте, скажем. Причём, конкретное представление (здесь - как FBD-схем) нейтральное или внешнее - зависит ещё и от реализации. Это всё не то - это всё вариации Оберона Вирта. Интересно узнать, чего же это такое - "совершенно недостаточно" из недавнего поста. Расширяемые структуры данных, процедурные типы, модули ... что ещё надо? или что-то совсем иное? Хотелось бы узнать, а что будет "совершенно достаточно"? Всё, что Вы перечисляете - не для внешних представлений - там, условно говоря, "деталь имеет тип детали, если она соответствует чертежу детали со всеми свойствами, представленными в предметно-специфических обозначениях". |
Автор: | Илья Ермаков [ Понедельник, 19 Сентябрь, 2011 18:57 ] |
Заголовок сообщения: | Re: ДРАКОН - схемы в работе, образовании и жизни |
alexus писал(а): И его "довесок" в виде ООП - это не потребность Оберон, а нечто вроде... "Хотите ООП?.. Нате вам... только отвяжитесь"... Что можно сделать нового с помощью ООП в Оберон, чего бы нельзя было сделать без него [без ООП]?.. Вот и нет. ООП позволило делать динамически расширяемые системы. Собственно, Вирт и сделал язык для написания своей новой ОС. Компонентное программирование, как течение в индустрии, началось как раз с того, что Вирт включил ООП в Оберон. Добавил к динамической модульности полиморфизм (динамическое связывание). Что из этого вышло, мы знаем, например, по работам Шиперского: http://oberoncore.ru/library/start (Object-orinetation in operation systems и Component Software Beyond Object-Oriented Programming). У нас про это хорошую статью написал Сергей Юрьевич Губанов: http://oberoncore.ru/articles/gubanov Конечно, но это не уровень моделирования, это более низкий уровень компоновки технической системы. Но лучше решить хорошо проблемы одного уровня и оставить другой людям на самостоятельное решение, чем получить неважное решение сразу обоих уровней. |
Автор: | alexus [ Понедельник, 19 Сентябрь, 2011 18:58 ] |
Заголовок сообщения: | Re: ДРАКОН - схемы в работе, образовании и жизни |
Драконограф писал(а): Жаль... если отталкивает частая категоричность суждений - так она тоже не "статична". Категоричность суждений, вопреки распространённому мнению, не всегда спутница глупости. Лично меня она ничуть не отталкивает. Но обсуждать/осуждать никого не стану...Драконограф писал(а): Скажем так - Илье Евгеньевичу и его единомышленникам... Илье Евгеньевичу я ответил, добавить пока нечего. Разница наших взглядов/рассуждений/умозаключений объясняется выбором подходов (программирование vs. моделирование). За несколько лет, наши подходы ничуть не сблизились (возможно, это объясняется различием в решаемых задачах... но скорее всего... разным мышлением...). С моей точки зрения, программная система - это не набор программ/модулей, это, прежде всего, архитектура... (уровни, интерфейсы, роли, классы, свойства, схемы и протоколы взаимодействия...). И код/кодирование в этой системе понятий... не первичный элемент.В этой связи... мне совершенно не интересно сравнивать разные языки программирования. На эту тему было много споров, которые сводятся к одному простому выводу: каждый пишет на том, что... лучше знает или на том, на чём требуют. Спорить о языках программирования, с точки зрения ООП, не более продуктивно. В 1992 году в "Мире ПК" я писал про ООП на ассемблере (тогда только вышел TASM 3.x). И "объектность" ассемблера мало чем отличается от "объектности" Оберона (гибкость выше, наглядность ниже... и всё). |
Автор: | Илья Ермаков [ Понедельник, 19 Сентябрь, 2011 19:04 ] |
Заголовок сообщения: | Re: ДРАКОН - схемы в работе, образовании и жизни |
alexus писал(а): С моей точки зрения, программная система - это не набор программ/модулей, это, прежде всего, архитектура... (уровни, интерфейсы, роли, классы, свойства, схемы и протоколы взаимодействия...). И код/кодирование в этой системе понятий... не первичный элемент. Полностью с Вами согласен. Я не представляю программу как текст/код. Я всегда представляю её как инженерную систему. Состоящую из компонент. Взаимодействующих через интерфейсы. И Оберон (в варианте КП, если Вы не в курсе, то здесь ООП усилено: http://oberon.ch/pdf/CP-New.pdf) позволяет мне хорошо это выражать. Не навязывая никаких шаблонов, позволяя создать свои кубики и соединять их, собирать из них систему. Модульность + полиморфизм - что ещё нужно от языка? Только чтоб не мешал! Оберон не мешает. |
Автор: | Владислав Жаринов [ Понедельник, 19 Сентябрь, 2011 19:13 ] |
Заголовок сообщения: | Re: ДРАКОН - схемы в работе, образовании и жизни |
Илья Ермаков писал(а): ... Как я понимаю, Александр всё-таки об уровне моделирования ("нейтральной схеме")... где он также предполагает всё-таки выражение не на прогязыке, а на "предметном"?..
Конечно, но это не уровень моделирования, это более низкий уровень компоновки технической системы. Но лучше решить хорошо проблемы одного уровня и оставить другой людям на самостоятельное решение, чем получить неважное решение сразу обоих уровней. |
Автор: | alexus [ Понедельник, 19 Сентябрь, 2011 19:17 ] |
Заголовок сообщения: | Re: ДРАКОН - схемы в работе, образовании и жизни |
Илья Ермаков писал(а): alexus писал(а): И его "довесок" в виде ООП - это не потребность Оберон, а нечто вроде... "Хотите ООП?.. Нате вам... только отвяжитесь"... Что можно сделать нового с помощью ООП в Оберон, чего бы нельзя было сделать без него [без ООП]?.. Вот и нет. ООП позволило делать динамически расширяемые системы.Илья Ермаков писал(а): Собственно, Вирт и сделал язык для написания своей новой ОС. Компонентное программирование, как течение в индустрии, началось как раз с того, что Вирт включил ООП в Оберон. Добавил к динамической модульности полиморфизм (динамическое связывание). Полиморфизм на основе интерфейсов... гораздо богаче полиморфизма на основе наследования. Поэтому оценить выбор Н.Вирта положительно, увы...Илья Ермаков писал(а): Что из этого вышло, мы знаем, например, по работам Шиперского: http://oberoncore.ru/library/start (Object-orinetation in operation systems и Component Software Beyond Object-Oriented Programming). Статья С.Ю. Губанова замечательная, хотя и не бесспорная. Например, он пишетУ нас про это хорошую статью написал Сергей Юрьевич Губанов: http://oberoncore.ru/articles/gubanov С.Ю. Губанов писал(а): Программирование модульных систем, вообще говоря, не требует обязательного использования объектно-ориентированного подхода и наоборот. Однако, одновременное использование этих двух подходов для построения расширяемых систем привело к появлению новой парадигмы программирования. Дело в том, что ООП, в его наиболее распространённой трактовке, основано на понятии наследования. При совместном использовании ООП и модульности возникнет межмодульное наследование, но оно является препятствием к взаимозаменяемости модулей от различных производителей. Если часть типа определена в одном модуле, а другая часть типа — в другом, то весьма проблематично модуль с базовым типом поменять на аналогичный модуль от другого производителя из-за возможных тонких различий в реализации. В 1995 году, профессор Клеменс Шиперски (Clemens Szyperski) сформулировал основные положения Компонентно-ориентированного подхода (КОП) через ограничения, накладываемые на модульный подход и на ООП для их непротиворечивого одновременного сосуществования («Component-Oriented Programming A Refined Variation on Object-Oriented Programming», The Oberon Tribune, Vol 1, No 2, December 1995). Цель КОП — построение расширяемых (в полном смысле этого слова) систем с помощью модулей и ООП. Таким образом, КОП находится (по мнению Шиперского) «За пределами ООП» (так называется его уже дважды изданная за рубежом книга-бестселлер, к сожалению, до сих пор не переведённая на русский язык). Фундамент КОП образуют: полиморфизм, позднее связывание, настоящая инкапсуляция, полный контроль безопасности со стороны среды времени исполнения. Замените слово "полиморфизм" на "интерфейсы" и исчезнет "объектность"... Но дело не простой в подмене понятий, а... в последовательности (разноуровневости) проектирования. Верхний уровень декларирует интерфейсы (что ему нужно от нижнего уровня), а нижний уровень группирует интерфейсы и формирует... описание модулей или классов. И т.д.Илья Ермаков писал(а): Конечно, но это не уровень моделирования, это более низкий уровень компоновки технической системы. Но лучше решить хорошо проблемы одного уровня и оставить другой людям на самостоятельное решение, чем получить неважное решение сразу обоих уровней. Вот об этом-то и речь...
|
Автор: | albobin [ Понедельник, 19 Сентябрь, 2011 20:05 ] |
Заголовок сообщения: | Re: ДРАКОН - схемы в работе, образовании и жизни |
Кстати об интерфейсах. Lagoona - тот же Оберон + "побольше интерфейса" Вирт отлично всё выбрал - самую суть. Небольшие вариации и - вот вам блюдо с фичами. |
Автор: | Владислав Жаринов [ Понедельник, 19 Сентябрь, 2011 20:09 ] |
Заголовок сообщения: | Моделирование и программирвание |
Я не пойму - так для проекта системы (того, что применительно к деятельности выражается, скажем на UML) предлагается тоже прогязык (скажем, Оберон) использовать? |
Страница 1 из 3 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |