Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 4086 18-04-2007 04:59 | |
Ответ на »сообщение 4078« (ASU)
___________________________
Если Вам так интересно, то почитайте работы на эту тему, или подумайте на предмет того, почему у слесаря 5 разряда тариф выше, чем, например, у слесаря 2 разряда...
Понятно. Поясню и это. Слесари разных разрядов готовят материальные вещи, которые можно оценить объективно, безотносительно предпочтений оценщиков. Качество программной системы -- это даже при привлечении экспертов высочайшей категории -- вкусовщина, субъективизм на уровне "нравится/не нравится".
Если Вы раздадите разряды программистам и будете считать, что решили задачу, то в условиях отсутствия действенного контроля со стороны ОТК над качеством программной системы всегда есть возможность схалтурить даже мастеру. Известно, что в сфере писательского дела короткие вещи писать сложнее, а пространные -- проще. Труд программиста в этом смысле очень напоминает труд писателя. Пиши тома, где суть растворена в толще страниц, и получай гонорары за новые творения на благо человечества. Нет никаких стимулов для того, чтобы трансформировать размусоленную в сотнях строк программную компоненту (модуль, класс, процедуру и т.п.) в компактную, функционально эквивалентную вещь. Качество разное!
№ 4085 18-04-2007 04:57 | |
Ответ на »сообщение 4082« (Руслан Богатырев)
___________________________
На самом деле имеем три системы
«Коль пошла такая пьянка»... то не три, а пять, но не систем, а моделей! (Кто больше!!!) :) анализ – проект – план – реализация – эксплуатация.
Так о каких системах мы дальше будем рассуждать? Давайте все же определяться.
О любых...
№ 4084 18-04-2007 04:50 | |
Ответ на »сообщение 4081« (AVC)
___________________________
А интерфейс "вагончик--рельсы" тот же самый, что и "вагончик--вагончик"?
Или это ошибка проектирования?
Угу... Б_А_Г_А! :)
№ 4083 18-04-2007 04:47 | |
Ответ на »сообщение 4063« (ASU)
___________________________
Ответ на »сообщение 4025« (MS)
___________________________
С этим не ко мне... С моей точки зрения, есть четкая последовательность:
процедуры -> библиотеки -> модули -> объекты -> агрегаты -> системы...
и никаких "противоборств"...
Насколько принципиально наличие в этом ряду библиотек и объектов? И именно в этих местах?
см. http://www.alexus.ru/russian/articles.htm
Извините, но просмотр Ваших Писем не помог :-(
Про библиотеки Вы говорите только в начале, обсуждая общие подходы, а объекты Вы объединяете в контейнеры, которых в приведённой последовательности нет (или Вы их назвали агрегатами?).
Что в приведённой последовательности предсталяет из себя библиотека? Это некий скомпилированный файл, содержащий набор процедур?
№ 4082 18-04-2007 04:42 | |
Ответ на »сообщение 4077« (ASU)
___________________________
Вы правильно рассуждаете... эволюционно, так сказать... накапливая количественные изменения... до качественного перехода.
Простите, я еще раз поясню, если не все понятно. Есть система. Называется компилятор. Она может быть подвергнута анализу и синтезу в соответствии с некоей методологией, а также получить свое воплощение в конкретном языке программирования (преломляясь через призму парадигм в данном языке). На выходе мы получаем реализацию системы.
На самом деле имеем три системы: система-замысел (уровень формулировки требований), система-проект (уровень методологии), система-реализация (уровень языка программирования). Они допускают вариативность на каждом из трех уровней: 1. Можно менять замысел, поскольку формулировка требований -- процесс, в который вовлечены, как минимум, две стороны -- заказчик и исполнитель; он может предусматривать предпроектные изыскания и принятие решений на уровне фиксации/конкретизации тех или иных требований.
2. Можно менять методологию (и отображение замысла на понятийный аппарат методологии).
3. Можно менять отображение проект в формулировке методологии на язык реализации.
В последнем случае можно выбирать различные способы отображения одной и той же методологии на один и тот же язык (эти схемы могут различаться спецификой требований к реализации -- платформы, операционнные среды, существующая программная инфраструктура, квалификация и оснащенность имеющихся в распоряжении исполнителей и т.п.).
Тот примел с компилятором, что я привел, касается вариативности только в отношении системы-реализации (язык один -- Оберон, но либо решение в один модуль, либо в несколько взаимодействующих). С точки зрения системы-замысла -- это система. С точки зрения системы-проекта -- это система. А с точки зрения системы-реализации (отображения проекта на конкретный язык реализации) -- как программа, так и система.
Так о каких системах мы дальше будем рассуждать? Давайте все же определяться.
№ 4081 18-04-2007 04:39 | |
Ответ на »сообщение 4074« (ASU)
___________________________
Поверьте, я к модульности отношусь с большой теплотой и трепетом :)
Представьте, что Вы с ребенком играете в «железную дорогу». Берете разные вагончики и тепловозики и сцепляете их между собой... Все вагончики разные: пассажирские, грузовые, цистерны и пр., а... интерфейс у всех один. Вагончики – модули, сцепка – интерфейс. Так понятнее? Я не отрицаю модульности, но множественность интерфейсов... как правило, следствие неудачного проектирования.
А интерфейс "вагончик--рельсы" тот же самый, что и "вагончик--вагончик"?
Или это ошибка проектирования?
На мой взгляд, модульность предполагает множественность интерфейсов.
А на мой... Интерфейсы и модули вообще разные понятия, и одно другого... даже не предполагает.
Вот где-то здесь мы и расходимся.
Значит, надо на таких пунктах и концентрироваться.
>>>А Вы что же -- тянете нас в каменный век? ;)
Строго наоборот... Именно к сборке я Вас и тяну... Посмотрите мои сообщения, с самого начала говорилось о том, что система должна конструироваться (собираться). Но это иной процесс, отличный от программирования и не разумно его выполнять из 3GL, нужен специализированный инструмент. Но не менее неразумно развивать 3GL в направлении конструирования систем... ничего хорошо из не может получиться.
Это действительно интересно.
№ 4080 18-04-2007 04:38 | |
Ответ на »сообщение 4057« (info21)
___________________________
>>>Нет никакой проблемы. И отдельных интерфейсов не нужно.
Нужно - не нужно, вопрос удобства.
Разумеется, вместо интерфейсов можно использовать "пустые" модули.
Вот только удобно ли это. На мой взгляд, разработка интерфейсов и их реализации достаточно сильно отличаются, чтобы не смешивать эти сущности в одной синтасической конструкции.
№ 4079 18-04-2007 04:33 | |
Ответ на »сообщение 4056« (Руслан Богатырев)
___________________________
>>>Я понимаю Ваше предубеждение в отношении работ Вирта по Оберону, якобы он шел по пути облегчения работы/структуры компилятора.
Кто хоть раз разрабатывал компилятор не может не смотреть на язык с этой точки зрения :)
Чем больше знакомлюсь с Обероном, тем сильнее ощущение, что с синтаксическим минимализмом случился перебор. Но это, конечно, субъективно.
№ 4078 18-04-2007 04:32 | |
Ответ на »сообщение 4076« (Руслан Богатырев)
___________________________
Проста, говорите? Мне это нужно комментировать? Ok.
Да, нет... Необязательно было комментировать... Понимаете, при нормировании используются не только чистое время, но и различные коэффициенты. Если Вам так интересно, то почитайте работы на эту тему, или подумайте на предмет того, почему у слесаря 5 разряда тариф выше, чем, например, у слесаря 2 разряда... Вы уж простите, что я не всю теорию нормирования и расчета трудозатрат рассказываю... Кстати, в исследованиях того же Тейлора было много поучительных моментов...
№ 4077 18-04-2007 04:25 | |
Ответ на »сообщение 4075« (Руслан Богатырев)
___________________________
Здесь уже обсуждали пример олимпиадной задачки с последнего чемпионата мира ACM по программированию. Она была решена (вариант на КП) в виде программы (одного модуля). Однако при этом выяснилось, что половину текста загромождает ввод-вывод и работа со строками. Я предложил вынести это со "сцены" в отдельный модуль. Простейшая декомпозиция. Перестала она после этого быть программой? Превратилась в систему? Если мы вынесем в модули еще некую специфику (передав на "аутсорсинг", на субподряд некий функционал), это станет системой?
Вы правильно рассуждаете... эволюционно, так сказать... накапливая количественные изменения... до качественного перехода. В какой-то момент наступит осознание того, что частями программы надо как-то управлять, и это управление к самим частям прямого отношения не имеет. Посмотрите на свой же пример с другой стороны. Есть некий «решатель» и есть некий «вывод», а система ими управляет. Если надо подключить новую часть (модуль, программу...), то не надо ничего менять во всех предыдущих частях, надо только слегка изменить логику управления и... все. Как в простейшем случае можно представить эту логику управления? AVC совершенно справедливо это отметил, например, как командная строка в UNIX, которая связывает выход одной программы со входом другой программы... Это простейший вариант, но... наглядный.
Компилятор -- вроде бы система (а что же еще?), но может быть реализована в виде монолитной программы, а может -- в виде набора модулей или даже совокупности взаимодействующих компонентов/объектов. Так когда же она из не-системы превращается в систему?
Да, конечно... Вы же не думаете, что системы рождаются из ничего...
Ваши комментарии?
См. выше...
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|