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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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


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

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

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

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


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

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

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

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

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


№ 5386   05-10-2007 09:48 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 5385« (Руслан Богатырев)
___________________________

Ответ на »сообщение 5384« (AVC)
___________________________

Способ борьбы со сложностью, вроде бы, только один: делить сложное на части и упрятывать детали реализации этих частей. Как мне кажется, именно это и делают модули.

Это один из возможных способов. Но не единственный.


А какой еще есть способ?


В "Рассуждении о методе" Декарт пишет: "Расчлените каждую изучаемую вами задачу на столько частей, на сколько сможете, и насколько это потребуется вам, чтобы их было легко решить". Расчленить –- это здорово. Но как? Вот в чём загвоздка. И Лейбниц обоснованно возразил Декарту: "Это правило Декарта малоэффективно, поскольку искусство разделения... остаётся неподдающимся истолкованию. Разделяя задачу на неподходящие части, неопытный решающий может увеличить свои затруднения".

Строго говоря, имеет смысл классифицировать ту сложность, с которой надо бороться. Для этого неплохо бы разобраться со сложностью решения задач, с процессом мышления при решении задач, а потом уже со сложностью сопутствующей инфраструктуры (включая инструменты). Первый шаг к этому попробовал сделать: см. "Джордж Пойа о решении задач в программировании" -- http://rbogatyrev.livejournal.com/2007/09/25/


Прочитал с большим интересом.
Вполне возможно, что и правда начинать надо с (анализа) процесса решения задач.
Вообще, интересно, что рассказывают хорошие математики о своем опыте математического мышления.
В свое время (давно) меня удивило утверждение Пуанкаре, что он никогда бы не мог стать хорошим шахматистом, т.к. его память для этого недостаточно хороша, а вот при решении математических задач он как-то особенно группирует их составные части, и поэтому справляется с их сложностью. (Это очень вольное изложение его слов, но Пуанкаре я читал очень давно.)
 AVC


№ 5385   05-10-2007 09:30 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 5384« (AVC)
___________________________

Способ борьбы со сложностью, вроде бы, только один: делить сложное на части и упрятывать детали реализации этих частей. Как мне кажется, именно это и делают модули.

Это один из возможных способов. Но не единственный.

В "Рассуждении о методе" Декарт пишет: "Расчлените каждую изучаемую вами задачу на столько частей, на сколько сможете, и насколько это потребуется вам, чтобы их было легко решить". Расчленить –- это здорово. Но как? Вот в чём загвоздка. И Лейбниц обоснованно возразил Декарту: "Это правило Декарта малоэффективно, поскольку искусство разделения... остаётся неподдающимся истолкованию. Разделяя задачу на неподходящие части, неопытный решающий может увеличить свои затруднения".

Строго говоря, имеет смысл классифицировать ту сложность, с которой надо бороться. Для этого неплохо бы разобраться со сложностью решения задач, с процессом мышления при решении задач, а потом уже со сложностью сопутствующей инфраструктуры (включая инструменты). Первый шаг к этому попробовал сделать: см. "Джордж Пойа о решении задач в программировании" -- http://rbogatyrev.livejournal.com/2007/09/25/

Требуется также выделить зоны профилактики, терапии и хирургии. В рамках проекта "Роса" это планируется делать.


№ 5384   05-10-2007 09:22 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 5383« (Руслан Богатырев)
___________________________

Ответ на »сообщение 5382« (AVC)
___________________________

А что Вас смутило в его ответе? По-моему, вполне взвешенный ответ.


Я просто хотел познакомить с ответом Зуева на заданный вопрос.
А то обсуждали, а самого автора не выслушали. :)

Вместе с тем, помнится речь шла о борьбе со сложностью (а не просто полезных фичах тех или иных языков).
Мой вопрос был вызван тем, что я не знаю других способов борьбы со сложностью, кроме модульности.
Если модульности мало (что вполне вероятно), что еще может помочь?
Способ борьбы со сложностью, вроде бы, только один: делить сложное на части и упрятывать детали реализации этих частей. Как мне кажется, именно это и делают модули.
 AVC


№ 5383   05-10-2007 06:18 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 5382« (AVC)
___________________________

А что Вас смутило в его ответе? По-моему, вполне взвешенный ответ.

Да, обязательно нужно стремиться к минимизации, но прежде всего стоит провести аккуратный анализ: почему то или иное свойство ничего не добавляет с точки зрения поддержки создания сложных программ, и как можно без него обойтись без потери надежности и сопровождаемости.

Разумеется, нужно иметь чувство меры, которое базируется на тщательном анализе, а не просто бегстве от проблем и непоняток. И по исключениям, и по маркировке экспорта я уже высказывал свое несогласие с подходом Вирта. Не надо впадать в крайности.

Выбросить из языка for-циклы и перечислимые типы - дело нехитрое; учить студентов азам программирования вполне возможно и без этих конструкций. А вот программировать в срок и согласно заданным требованиям огромные, сверхсложные, долгоживущие, развиваемые и сопровождаемые системы - не знаю...

С моей точки зрения, и FOR, и перечисление в императивном языке нужны.


№ 5382   05-10-2007 04:55 Ответить на это сообщение Ответить на это сообщение с цитированием
Некоторое время назад мы обсуждали пост в блоге Евгения Зуева.
(Я там высказывался несколько критически... :) ).
К сожалению, я скоро перестал сделить за комментариями, а Евгений Зуев ответил мне и довольно оперативно (это первый раз, когда блоггер подробно ответил на мой комментарий, поэтому я себя прощаю -- на первый раз :) ).

Ответ Зуева здесь:
https://www.blogger.com/comment.g?blogID=8224163229837394669&postID=8278351721766019026

To AVC:

>Интересно, почему модульности очевидно недостаточно
> для борьбы со сложностью?

Э-э-э... А что, достаточно? То есть, в языке достаточно иметь модули, и они одни способны решить все проблемы создания больших программ? Я что-то не понял реплики, простите.

>И если модульности недостаточно, то какое
> языковое свойство справится с этой задачей лучше?

Еще раз простите, но тут что-то не в порядке с логикой. Да, модульности недостаточно, но это вовсе не означает, что модульность надо заменить на что-то, что "справится с задачей лучше".

Мой "пойнт" в том, что модульность крайне необходима в языке. Более того: ее наличие даже важнее, чем наличие полноценной поддержки ООП. По крайней мере, никак не менее важно.

Но это вовсе не означает, что модулей и процедур _достаточно_. В комментарии невозможно "огласить полный список" свойств, критичных для создания _больших_ и _сложных_ программ. Предельно кратко (и банально):

- типовАя параметризация
- полноценная поддержка ООП, включая интерфейсы/контракты
- механизм исключительных ситуаций, интегрированный с ООП

Кстати: в том и состоит _настоящая_ сложность проектирования языка для больших задач, чтобы включить в его состав все необходимое, но не больше. Именно _специфицировать_, что действительно необходимо, а что действительно не нужно.

Да, обязательно нужно стремиться к минимизации, но прежде всего стоит провести аккуратный анализ: почему то или иное свойство ничего не добавляет с точки зрения поддержки создания сложных программ, и как можно без него обойтись без потери надежности и сопровождаемости.

Выбросить из языка for-циклы и перечислимые типы - дело нехитрое; учить студентов азам программирования вполне возможно и без этих конструкций. А вот программировать в срок и согласно заданным требованиям огромные, сверхсложные, долгоживущие, развиваемые и сопровождаемые системы - не знаю...


Интересно, что вы думаете по поводу этого ответа?
 AVC


№ 5381   03-10-2007 02:14 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 5380« (Как слышно? Приём!)
___________________________

Так вот, чтобы постановщик мог найти ошибку он должен иметь возможность копаться в том, что нагородил кодер. Речь об этом. Инженеру, специалисту в своей области, легче разобраться в императивной программе, чем в программе на ФЯ (при достаточной сложности)
Запинается о порог вхождения.

Как говорится, "это зависит..." Смотря какие задачи, смотря какие инструменты...

На Хаскелле, например, можно спецификацию/описание программы превратить в саму программу, так называеый прицип "Running the manual". Примеры такого подхода - то же самое верифицированное микроядро seL4, или давным давно упоминавшаяся работа %url["Haskell vs. Ada vs. C++ vs. Awk vs. ... An Experiment in Software Prototyping Productivity" by Paul Hudak & Mark P. Jones,]Haskell vs. Ada vs. C++ vs. Awk vs. ... An Experiment in Software Prototyping Productivity. Paul Hudak. Mark P. Jones. Yale University ... в которой программа авторов фактически была исполняемой спецификацией...

Если постановщик задачи сможет без всяких заморочек запустить на выполнение только что поставленную им задачу, то нужда в кодерах резко сократится. Конечно, no silver bullet, и вероятно такая спецификация будет не очень шустрой программой, но для многих случаев это вполне допустимо, а когда прижмёт, можно обратиться к более опытному программеру за более оптимальным алгоритмом, если это действителльно так уж необходимо...

Вот в теме по ФП часто приводился такой пример быстрой сортировки на Хаскелле:

qs [] = []
qs [x] = [x]
qs (x:xs) = qs (filter (< x) xs) ++ (x:filter (== x) xs) ++ qs (filter (> x) xs)

Если честно, то это довольно медленный вариант сортировки, но вот если нужен Вам, например, только первый элемент отсортированного списка - Вы его получите за время, пропорциональное длине массива (O(n)), а не за O(n*log(n))...


№ 5380   03-10-2007 01:23 Ответить на это сообщение Ответить на это сообщение с цитированием
Есть программа правильная с точки зрения кодера, а есть с точки зрения постановщика.

Так вот, чтобы постановщик мог найти ошибку он должен иметь возможность
копаться в том, что нагородил кодер. Речь об этом. Инженеру, специалисту в своей области,
легче разобраться в императивной программе, чем в программе на ФЯ (при достаточной сложности)
Запинается о порог вхождения.

Для постановщика найти оксиморон - найти ключ к решению задачи "под ключ".
А для кодера - это глупость. Ведь задача удовлетворяет ТЗ.
А ТЗ пусть марсиане готовят и за него отвечают.


№ 5379   02-10-2007 16:49 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 5371« (Как слышно? Приём!)
___________________________

Видимо, разница в подходах в том, что можно решать уже сформулированную задачу со своим ТЗ и спецификациями, которые считаются истиной в последней инстанции.
Достигнуто соответствие - программа правильная, а там хоть не рассветай.

Если у Вас в ТЗ ошибка, то правильный продукт Вы получите разве что по ошибке... :о))


№ 5378   02-10-2007 16:43 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 5371« (Как слышно? Приём!)
___________________________

Кстати, а что такое Оксюморон?

Оксюморон

Материал из Википедии — свободной энциклопедии

Оксюморон (оксиморон; др.-греч. ????????, буквально — остроумная глупость) — стилистическая фигура, или стилистическая ошибка — сочетание слов с противоположным значением. Таким образом, слово «оксюморон» само по себе является оксюмороном.

Например: «горячий лёд», «далекое близкое», «живые мертвецы» и т. п.

Любой оксюморон является противоречием. Характерным для оксюморона является намеренное использование противоречия, для создания стилистического эффекта.

Оксюморон нередко используется в названиях литературных произведений: «Горячий снег», «Бесконечный тупик», «Слепящая тьма», «C широко закрытыми глазами», «Жар холодных чисел», «Живой труп».


№ 5377   02-10-2007 16:07 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 5375« (Jack Of Shadows)
___________________________

>Ну, до реализации Росы еще года два минимум ждать
Вы чрезвычайно оптимистичны :))


Смотря что понимать под реализацией. Макетирование начнется достаточно скоро. И хотя обещанного, как известно, три года ждут, результаты начнут проявляться, мягко говоря, несколько раньше. При этом показывать на публике из сырого имеет смысл в том случае, когда есть желание получить полезную обратную связь. Она нужна для принятия решений, для уточнения выбора, для поиска новых участников и помощников.


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


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

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

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

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

Перейти на конкретную страницу по номеру
  
Время на сайте: 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» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

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