Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 5386 05-10-2007 09:48 | |
Ответ на »сообщение 5385« (Руслан Богатырев)
___________________________
Ответ на »сообщение 5384« (AVC)
___________________________
Способ борьбы со сложностью, вроде бы, только один: делить сложное на части и упрятывать детали реализации этих частей. Как мне кажется, именно это и делают модули.
Это один из возможных способов. Но не единственный.
А какой еще есть способ?
В "Рассуждении о методе" Декарт пишет: "Расчлените каждую изучаемую вами задачу на столько частей, на сколько сможете, и насколько это потребуется вам, чтобы их было легко решить". Расчленить –- это здорово. Но как? Вот в чём загвоздка. И Лейбниц обоснованно возразил Декарту: "Это правило Декарта малоэффективно, поскольку искусство разделения... остаётся неподдающимся истолкованию. Разделяя задачу на неподходящие части, неопытный решающий может увеличить свои затруднения".
Строго говоря, имеет смысл классифицировать ту сложность, с которой надо бороться. Для этого неплохо бы разобраться со сложностью решения задач, с процессом мышления при решении задач, а потом уже со сложностью сопутствующей инфраструктуры (включая инструменты). Первый шаг к этому попробовал сделать: см. "Джордж Пойа о решении задач в программировании" -- http://rbogatyrev.livejournal.com/2007/09/25/
Прочитал с большим интересом.
Вполне возможно, что и правда начинать надо с (анализа) процесса решения задач.
Вообще, интересно, что рассказывают хорошие математики о своем опыте математического мышления.
В свое время (давно) меня удивило утверждение Пуанкаре, что он никогда бы не мог стать хорошим шахматистом, т.к. его память для этого недостаточно хороша, а вот при решении математических задач он как-то особенно группирует их составные части, и поэтому справляется с их сложностью. (Это очень вольное изложение его слов, но Пуанкаре я читал очень давно.)
№ 5385 05-10-2007 09:30 | |
Ответ на »сообщение 5384« (AVC)
___________________________
Способ борьбы со сложностью, вроде бы, только один: делить сложное на части и упрятывать детали реализации этих частей. Как мне кажется, именно это и делают модули.
Это один из возможных способов. Но не единственный.
В "Рассуждении о методе" Декарт пишет: "Расчлените каждую изучаемую вами задачу на столько частей, на сколько сможете, и насколько это потребуется вам, чтобы их было легко решить". Расчленить –- это здорово. Но как? Вот в чём загвоздка. И Лейбниц обоснованно возразил Декарту: "Это правило Декарта малоэффективно, поскольку искусство разделения... остаётся неподдающимся истолкованию. Разделяя задачу на неподходящие части, неопытный решающий может увеличить свои затруднения".
Строго говоря, имеет смысл классифицировать ту сложность, с которой надо бороться. Для этого неплохо бы разобраться со сложностью решения задач, с процессом мышления при решении задач, а потом уже со сложностью сопутствующей инфраструктуры (включая инструменты). Первый шаг к этому попробовал сделать: см. "Джордж Пойа о решении задач в программировании" -- http://rbogatyrev.livejournal.com/2007/09/25/
Требуется также выделить зоны профилактики, терапии и хирургии. В рамках проекта "Роса" это планируется делать.
№ 5384 05-10-2007 09:22 | |
Ответ на »сообщение 5383« (Руслан Богатырев)
___________________________
Ответ на »сообщение 5382« (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-циклы и перечислимые типы - дело нехитрое; учить студентов азам программирования вполне возможно и без этих конструкций. А вот программировать в срок и согласно заданным требованиям огромные, сверхсложные, долгоживущие, развиваемые и сопровождаемые системы - не знаю...
Интересно, что вы думаете по поводу этого ответа?
№ 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)
___________________________
>Ну, до реализации Росы еще года два минимум ждать
Вы чрезвычайно оптимистичны :))
Смотря что понимать под реализацией. Макетирование начнется достаточно скоро. И хотя обещанного, как известно, три года ждут, результаты начнут проявляться, мягко говоря, несколько раньше. При этом показывать на публике из сырого имеет смысл в том случае, когда есть желание получить полезную обратную связь. Она нужна для принятия решений, для уточнения выбора, для поиска новых участников и помощников.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|