Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  23:24[Войти] | [Зарегистрироваться]
Обсуждение темы:
Оберон-технология: особенности и перспективы


Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение. 

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 6256 сообщений

Добавить свое сообщение

Отслеживать это обсуждение

Обсуждение из раздела
Школа ОБЕРОНА

<<<... | 5386—5377 | 5376—5367 | 5366—5357 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 89


№ 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 смысла не вижу. Тем более, что ряд вещей с большой долей вероятности (после значительной переработки) войдет в проект "Роса". А там подход с вывалом наружу исходников (типа -- "берите что не жалко и разбирайтесь сами") недопустим. Сначала будет публичное обоснование выбора проектных решений (с пояснением вариативности), потом проектная документация (вкл. спецификации) и только потом -- исходники (как иллюстрация спецификаций).


<<<... | 5386—5377 | 5376—5367 | 5366—5357 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 89


Добавить свое сообщение

Отслеживать это обсуждение

Дополнительная навигация:
Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру
  
Время на сайте: GMT минус 5 часов

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

Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

 
© При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

Яндекс цитирования