Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 5376 02-10-2007 15:59 | |
Ответ на »сообщение 5373« (Jack Of Shadows)
___________________________
Оксюморон это бессмысленное словосочетание.
В таком значении лучше применять слова "нонсенс", "абракадабра".
Оксюморон же имеет иной смысл -- это видимый парадокс, эпатирующие противоречия. Т.е. с виду антонимическая глупость (совмещать несовместимое, вроде "тупая острота"), а на самом деле может быть заложен глубокий смысл, ибо в противостоянии несовместимого и выражается бытие, и раскрывается сознание. В оксюмороне совмещают обычно прилагательное (свойство, признак) с существительным (сущностью). Можно вспомнить Юрия Лотмана и приводившийся им оксюморон: "Он возлюбил страшное веселие лица его". Оксюморон нередко есть противопоставление бытия и отношения к нему сознания.
№ 5375 02-10-2007 15:51 | |
Ответ на »сообщение 5374« (qwerty)
___________________________
Ну, до реализации Росы еще года два минимум ждать
Вы чрезвычайно оптимистичны :))
№ 5374 02-10-2007 15:41 | |
Ответ на »сообщение 5367« (Руслан Богатырев)
___________________________
Для подобных инфраструктурных вещей (вроде ЛОТОС), которые несут в себе немало новых абстракций и проектных решений, вываливать наружу исходники на Модуле-2 смысла не вижу. Тем более, что ряд вещей с большой долей вероятности (после значительной переработки) войдет в проект "Роса".
Ну, до реализации Росы еще года два минимум ждать, тем более будет значительная переработка.
Интересно то, что есть сейчас.
№ 5373 02-10-2007 14:59 | |
Ответ на »сообщение 5371« (Как слышно? Приём!)
___________________________
Кстати, а что такое Оксюморон?
Оксюморон это бессмысленное словосочетание.
№ 5372 02-10-2007 14:55 | |
>>> Собственно говоря, серебряная пуля может быть направлена разве что в сердце разработчика.
Оба на! Оборотни в погонах - это уже привычно, а оборотни в дебагерре - это ново! :)
№ 5371 02-10-2007 14:51 | |
Ответ на »сообщение 5368« (Geniepro)
___________________________
>>> Правильная программа, которая решает не ту задачу
В программе нет утечек памяти, все конструкторы имеют деструкторы, исключения обрабатываются в полном объёме, модель похожа на ту, которая в таких случаях принято принимать,
соблюдены некие правила хорошего кодинга, но задачу не решает.
Например, в модели нет важных специфичных для данного случая деталей.
Видимо, разница в подходах в том, что можно решать уже сформулированную задачу
со своим ТЗ и спецификациями, которые считаются истиной в последней инстанции.
Достигнуто соответствие - программа правильная, а там хоть не рассветай.
Другое дело добиться решения информационной задачи взятой из реальности.
Со сменой ТЗ до тех пор пока эта цель не достигнута.
Вот Вам и разница между правильной программой и программой, решающей задачу.
Кстати, а что такое Оксюморон?
№ 5370 02-10-2007 09:58 | |
Ответ на »сообщение 5368« (Geniepro)
___________________________
А если подходить с Вашим подходом, то можно любую программу объявить правильной (в каком-то смысле), независимо от того, решает ли она хоть какую-то задачу...
Между задачей и программой большая пропасть. Которую позволяют в определенном смысле преодолеть требования и спецификации. Как проверить соответствие спецификаций задаче? А соответствие программы спецификации? Кто и как формирует спецификации на адаптивность программы (адаптивность спецификаций) к изменению требований задачи и условий применения?
Правильность программы (и не только ее) просто так не бывает. Правильность рассматривается по отношению к чему-то. В случае программы -- по отношению к чему смотрим правильность? По отношению к спецификации? Это непротиворечивость, корректное соответствие, но вряд ли правильность. Правильность по отношению к синтаксическим правилам языка реализации? Это обычно возложенно на компилятор. Поведенческая правильность? Соответствие эталонным тестам? Не все так просто...
№ 5369 02-10-2007 09:47 | |
Ответ на »сообщение 5363« (Как слышно? Приём!)
___________________________
По поводу контроля сложности. Процитирую сам себя:
"управление сложностью больших систем - это та же ручная работа".
Обратите внимание - "та же". То есть та же, что и в Обероне, например.
Нету тут ни плюса у ФЯ, ни серебра.
Собственно говоря, серебряная пуля может быть направлена разве что в сердце разработчика. Поскольку программируют люди, то и сложности себе создают они же. Сложности эти разные. Но в конечном счете упираются в пресловутый вопрос "как человек мыслит". Разумеется, не в таком общем виде. А как мыслит при решении задач, при продумывании и создании программных систем. Двадцать лет назад я потратил лет 5 на то, чтобы разобраться в этом вопросе под определенным углом зрения (системы реального времени) исходя из ситуации тех лет (методология разработки сложных программных систем была и темой дипломной работы). Сейчас много больше накоплено опыта и новой информации. При этом судя по моему прошлогоднему анализу, который предшествовал решению "прыгнуть" в проект новой ОС, существенных подвижек в этом деле не произошло. Более того, появилось много искусственно привнесенной сложности.
У меня сложилось устойчивое понимание того, что "полная автоматика" в этом вопросе -- иллюзия решения, но не решение. Постфактумная верификация, равно как и автоматическое распараллеливание имеют существенные ограничения. Другими словами, абстрагироваться от человека нельзя. А раз так -- важно осознать, какие виды сложностей он сам себе создает и потом героически их преодолевает. Важно понять, что жонглирование парадигмами в рамках одного языка -- это ущербная практика, порождающая сильно недооцененные проблемы. Разумнее иметь компактные миры, заточенные на те или иные парадигмы, дабы убрать зоны утечки контроля сложности и свести работу программиста к переключению "контекста" (настройки мышления на конкретную парадигму). Эти миры должны гармонично взаимодействовать, создавая при этом устойчивые сочетания (как в свое время задумывалась и реализовывалась система "Модула-Лисп-Пролог").
Важно понимать, что программирование -- это не просто кодирование. Что это более глубинная сфера. Что спецификации (не важно в каком виде: графическом, текстовом) -- это те же программы, но представленные на ином уровне абстракций. Что спецификации могут абстрагироваться от конкретного языка программирования, но на определенном уровне должны нести в себе вариативную "хинтовку" применимости тех или парадигм и подходов. Использовать их понятийный аппарат.
Важно также понимать, что границы самих парадигм сильно размыты приливной волной конъюнктуры (рыночной и научной). Что представление о том, что есть ООП, что есть ИП, что есть ФП -- сильно расплывчатое. И что судить об этом нам приходится все больше по конкретным экземплярам, по конкретным особям современного "зоологического сада".
№ 5368 02-10-2007 09:13 | |
Ответ на »сообщение 5363« (Как слышно? Приём!)
___________________________
Есть правильные программы и программы, которые соответствуют задаче.
Разницу понимаете?
Абсолютно не понимаю... :о(
Сами говорили, что в ФЯ программа на себя берёт массу рутинной работы, не давая программисту
ошибиться в этой части.
Но тем самым в ФЯ меньше контакта с требухой программы и, соответственно,
меньше контроля за исполнением.
В случае, если есть подозрение, что правильная программа решает по сути не ту задачу,
то выяснение происхождения ошибки в представляется на основании этих аргументов
в ФЯ более трудным, чем в ИЯ. Что не так?
Что значит: "Правильная программа, которая решает не ту задачу"? Оксюморон какой-то...
Программа либо правильная, и тогда она решает нужную задачу, либо неправильная...
Программа либо решает нужную задачу, и тогда она правильная, либо не решает нужную задачу...
А если подходить с Вашим подходом, то можно любую программу объявить правильной (в каком-то смысле), независимо от того, решает ли она хоть какую-то задачу...
№ 5367 02-10-2007 09:07 | |
Ответ на »сообщение 5366« (qwerty)
___________________________
Спасибо. А что-нибудь из этого доступно в исходниках?
Коммерческие и корпоративные вещи однозначно нет. Исследовательские -- можно подумать. Не очень только понятна цель "посмотреть исходники".
Для подобных инфраструктурных вещей (вроде ЛОТОС), которые несут в себе немало новых абстракций и проектных решений, вываливать наружу исходники на Модуле-2 смысла не вижу. Тем более, что ряд вещей с большой долей вероятности (после значительной переработки) войдет в проект "Роса". А там подход с вывалом наружу исходников (типа -- "берите что не жалко и разбирайтесь сами") недопустим. Сначала будет публичное обоснование выбора проектных решений (с пояснением вариативности), потом проектная документация (вкл. спецификации) и только потом -- исходники (как иллюстрация спецификаций).
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|