Приведу несколько цитат из упоминавшейся книги Дж.Пойа (вторую, кстати, -- "Математика и правдоподобные рассуждения" тоже при наличии времени и желания имеет смысл изучить). Для тех, кто хочет сразу понять, какое это отношение имеет к программированию -- попробуйте абстрагироваться от того, что Пойа раскрывает школьным учителям кухню мышления математика при решении задач, а подумайте, что он рассказывает о том, как надо мыслить при программировании -- для особо нетерпеливых рекомендую начинать сразу с части 2 "На пути к общему методу". Математические примеры воспринимайте просто как иллюстрацию глубинных идей Пойа.

"Решение задач -- специфическое достижение разума, разум же -- особый дар, которым наделен человек. Способность к преодолению препятствий, к нахождению обходного маневра там, где не видно прямого пути, возвышает умное животное над тупым, человека -- над самым умным животным и талантливых людей -- над другими людьми".

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

Сергей Перовский здесь уже высказывал мысль о том, что в школе неразумно давать обобщение, которое потом конкретизировать. Полностью согласен. В контексте мысли Пойа: обобщение надо понять, прочувствовать, набить шишек, только тогда можно осознанно на основе удачного обобщения получать много ценной практической конкретики. Продолжу мысль: не язык Оберон (КП) надо преподавать, а разбирать по косточкам систему Оберон (BlackBox), выявляя там обобщающие решения, которые можно применить в будущем в любом другом языке. Замените язык Оберон на язык Haskell, систему Оберон на конкретную практически ценную систему, реализованную на Хаскеле -- смысл тот же. В массы надо продвигать не инструментарий, не библиотеки, а готовые полезно-показательные программы. Разбирая их по косточкам.

Движение open-source полезно для халявного использования, но мало дает пользы для познания. Открытое документирование (где исходники -- просто иллюстрация) много полезнее в плане передачи знаний и технологий, а также быстрой адаптации кем-то найденных и изученных решений для своих практических задач. Но идеал -- совмещение того и другого. Книги Вирта, кстати, ценны именно этим -- примеры, приводящие к сути метода с пояснением выбора проектных решений. Кстати, подготовка документированной задачки из чемпионата мира ACM -- из той же серии. Вроде небольшой масштаб, но немалая практическая ценность.

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

Сопоставлять эффективность разных реализаций ФП с ИП, на мой взгляд, не совсем продуктивно. И вот почему. Любой ФП "плавает" на ран-тайме, реализованном на ИП. Можно считать, что это особый сильно заоптимизированный слой библиотек ИЯ. Только ИЯ с ним работает как с внешней библиотекой, а ФЯ -- как со встроенным механизмом. При том, что синтаксис ФЯ затачивается под эту библиотеку. Если исходить из этого, то разницы быть не должно, более того, встроенные средства могут быть плотнее оптимизированы.

Следовательно, различие кроется в мышлении и том наборе средств, которыми оперирует программист. Лично я сильно сомневаюсь, что для решения задач программист, стоящий в каждый момент времени перед вариативностью пути реализации, проводит полноценные "предпроектные изыскания" и оценивает на основе объективных вещей, какой вариант лучше. Это скорее исключение. А правило -- работа по шаблонным схемам, которые диктует его опыт и рабочий инструмент (лежащий в рамках доминирующей там парадигмы).

Я уже говорил, что ФП ключевой сущностью является функция, в МП – модуль, а в ООП -- класс. При этом функция и класс самодостаточны, а модуль -- контейнер других сущностей. Суть работы в каждой из этих парадигм -- композиция ключевых сущностей. В ООП устанавливается жесткая межсущностная связь на основе одного взгляда (классификация). Ошибка в классификации критична. Если классификация уже отчуждена, вносить в нее изменения крайне затруднительно. Уж как сделали, так сделали. Можно только наращивать и ставить заплаты. В МП межсущностная связь слабее (экспорт-импорт). Но с содержимым "коробки" (модуля) можно ошибиться, равно как и в масштабе и составе модулей. Это парадигма, много более устойчивая к проектным ошибкам и сопровождению/модификации. Что касается ФП, то построение отображений (суть функций) требует не меньшей осторожности, чем построение классификации в ООП, хотя и определенно гибче (менее чувствительна к ошибкам).

В ИП во главу угла поставлено управление, в ФП -- данные и их обработка, в ООП -- моделирование (имитационное). Соответственно, в этих сферах они дают максимальный эффект.

В ООП требуется движение от частного к общему: сначала нужно получить конкретику (примеры, ситуации, сценарии и т.п.), а потом ее обобщить (хотя в действительности этим часто пренебрегают). В ИП (МП) и ФП допустимы оба направления, но стимулируется движение от общего к частному (декомпозиция на модули, декомпозиция на процедуры/функции). ФП заточено под работу с динамическими структурами произвольной сложности, в идеале -- отложенное исполнение (работа "по готовности").  ИП (МП) -- на непосредственно исполняемые действия  (работа "по прерыванию"), на пошаговое препарирование (вплоть до "железа") алгоритмов. МП делит задачу на блоки, но не дает строгого критерия деления. ООП не делит, а классифицирует (задает множество моделей, удовлетворяющих построенной классификации). ФП делит задачу, но не на блоки, а на решения.

Программирование -- это сознательный поиск средства для достижения ясно видимой, но недоступной цели. Если средство есть (под рукой, "нажми кнопку -- получишь результат"), то нет и проблемы. Найти решение задачи (в понимании Дж.Пойа) -- это значит установить связь между заранее дифференцированными объектами (классы в ООП) или идеями (функции). ИП в одеждах  МП (в контексте Оберонов) -- это объединение возможностей ФП и ООП (не всех, а существенных) без "жесткости" ограничений ФП и ООП. Но за все надо платить. Это не панацея.

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

Что-то я искал, искал, не смог найти... :о(
А где именно? В каком разделе? А ещё лучше - прямая ссылка...

Пока там еще идет работа по кардинальной реконструкции, жизнь теплится только на небольшом участке, "Новые поступления" -- http://www.europrog.ru/ilog.html

Имейте в виду, что объемы PDF, построенных на отсканированных страницах оригинала, немалые(указаны при наведении мыши на значок PDF около соотв. материала). В ближайшие дни к основному формату будут выкладываться вспомогательные (оптимизированные, в частности DjVu). Там выигрыш в объеме на отсканированных страницах достигает 3-5 раз.

Ответ на »сообщение 2485« (Руслан Богатырев)
___________________________

А если Вы хотите глубже разобраться в сути программирования, в том, что из себя представляет эта форма интеллектуальной деятельности, перечитайте неторопливо и обстоятельно книгу Джорджа Пойа "Математическое открытие" (есть на EuroProg).

Что-то я искал, искал, не смог найти... :о(
А где именно? В каком разделе? А ещё лучше - прямая ссылка...

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

Суть - в наличие того, что выделено. А если такого старания не наличиствует в принципе? Льют, что слюна на язык принесла! "Работает же!"
По моим прикидкам, 7 из 10 (примерно) людей, которым я давал ссылку на эту ветку просто не понимают предмета обсуждения...

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

"Работает -- и ладно". Вот доминирующий принцип современного программирования. Профессора идут на поводу у индустрии: зачем напрягать мозговые извилины своих студентов (никакой мотивации ни у тех, ни у других), если в конечном счете тот, кто пересечет финишную ленточку первым, сорвет основной куш (а на "допинг" и его последствия наплевать). Принцип столбить идею до ее обкатки, пришедший из мира науки, пропитал собой мир компьютерного бизнеса. Главное столбить, расставлять вешки с угрожающей надписью "Мое -- не трожь".

А почему такой бардак? Все от безнаказанности. Нет контроля (ни внутреннего, ни внешнего), нет неотвратимости наказания. Многие живут сегодняшним днем. А что и где "рванет" завтра -- не моя забота. Мы еще и на разборе "завалов" подзаработаем...

Думаю, многим известны "золотые слова" Хоара: "Почти все в программном обеспечении может быть реализовано, продано и даже использовано, если проявить достаточную настойчивость... Но существует одно качество, которое нельзя купить, -- это надежность. Цена надежности -- погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить". -- Тони Хоар (Великобритания, Оксфордский университет, из речи при вручении премии Тьюринга -- Нэшвилл, США, 27 октября 1980 г.). Ему вторит его близкий друг и коллега Никлаус Вирт: "Мы живем в сложном мире и стараемся решать сложные по своей сути проблемы, которые зачастую для своего решения требуют сложных устройств. Однако это не значит, что мы не должны найти элегантные решения, убеждающие своей ясностью и эффективностью. Простые элегантные решения более эффективны, но найти их труднее, чем сложные, и для этого требуется больше времени. -- Никлаус Вирт (Швейцария, ETH Zurich -- из речи при вручении премии Тьюринга -- Сан-Франциско, США, октябрь 1984 г.).

А насчет непонимания предмета обсуждения в этой ветке -- не удивляйтесь. Человек должен быть настроен на восприятие информации, иначе не будет эффекта "резонанса". Он должен быть мотивирован (понять, зачем ему это нужно). А идентифицировать мотивацию у тех, кто вырос (и в профессиональном плане) на стереотипах рынка, очень непросто. Зачем что-то менять, если и так нормально? Там вон появилась крутизна в любимом языке (среде), тут кто-то что-то сказал о новациях -- надо покумекать, наверно, стоящая вещь. Вообще мир сейчас просто поражен этим вирусом, этим наркотиком под названием "инновации". Это же замечательно, все мы грешны и падки на новое. Сколько можно навешать лапши руководству, клиентам, коллегам! А какие под это деньги можно выбить! И какую карьеру построить!

Расскажу Вам такую историю (взял фрагмент в одной из своих статей, которые сейчас еще в подготовке к публикации). В конце января этого года на сайте старейшей в Европе компьютерной ассоциации -- Британского компьютерного общества (British Computer Society), отмечающей в этом году свое 50-летие, была опубликована заметка под броским заголовком -- "Гибель компьютинга" (Death of Computing).

Ее автор -- преподаватель информационно-коммуникационных технологий (ИКТ) из английской "глубинки" выдвигает тезис о том, что настало время иначе взглянуть на роль фундаментальных знаний в сфере ИКТ. Если раньше на научный статус компьютерных наук никто не посягал, то теперь мы становимся свидетелями того, что 8-летний карапуз своими руками создает виртуальных роботов без знания программирования и математики. Миновали те дни, когда всем заправляло программирование на ассемблере, когда программирование волновало воображение и было передовым рубежом науки, когда создавались сети компьютеров и требовалось заполнить белые пятна на карте мира прикладных программ. Все это осталось в прошлом. Сегодня корабль получил пробоину ниже ватерлинии. В США число студентов, выбравших компьютерные науки, за период с 2000 по 2005 гг. упало на 39%. В Австралии на повестке дня вопрос о сокращении преподавательского состава по ИТ-дисциплинам. Прерывания, циклы, алгоритмы, формальные методы -- все это ничего не значащие слова. ИТ-индустрии нужны ресурсы для удовлетворения все возрастающих информационных потребностей рынка. Наша жизнь в 21-м веке кардинально изменилась по сравнению с тем, что было в 1960-х, 70-х, 80-х и даже в начале 90-х годов. Компьютеры стали неотъемлемой частью нашего существования -- они унифицированы и вездесущи.

Что же, по мнению этого "революционера", надо делать? Разумеется, отбросить старые оковы, мешающие двигаться на пути прогресса. Нужны инновации, креативность, "дивергенция мышления". Новые факультеты компьютинга в высшей школе должны стать факультетами междисциплинарными, вбирающими в себя идеи из биологии, дизайна, истории, медицины. Это даст жизнь новой дисциплине -- новому компьютингу 21 века! Что тут сказать? Если бы дело происходило не в консервативной Британии, а по ту сторону Атлантического океана, была бы еще понятна подобная риторика. Но здесь... Здоровый прагматизм против "научного идеализма"?

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

В марте-апреле 2006 г. два ведущих американских университета -- Стенфордский университет  и университет Карнеги-Меллон отпраздновали своеобразные юбилеи: их факультетам компьютерных наук (computer science) исполнилось соответственно 40 и 50 лет. В связи с этим американский еженедельник Computerworld задал вопросы профессорам ведущих американских университетов. Вот два ярких критических взгляда. Рандел Брайант (Randal Bryant, Карнеги-Меллон) отмечает: "Мы должны прекратить практику запугивания студентов. Прогнозы относительно того, что все вакансии в сфере информационных технологий переместятся в офшор, могут стать деструктивными. Новые рабочие места появляются быстрее, нежели старые перемещаются в офшор, и эта тенденция будет продолжаться. Нам необходимо очнуться от спячки. Студенты, которые изучали в средней школе информатику, обучены тому, как писать программы на Java. Их научили писать код, который делает скучные вещи вроде сортировки списка чисел. Они ничего не знают о крупных идеях в области компьютерных наук". Бернар Шазель (Bernard Chazell, Принстонский университет): "Многие учебные программы устарели. Почему мы сегодня все еще уделяем лишь беглое внимание ассемблеру? Некоторые наши учебные программы строятся почти целиком вокруг овладения языком Java. Это преступно".

Итак, с одной стороны, от прогресса никуда не уйти. Чтобы двигаться вперед, нужны новые идеи, инновации. А с другой... Прогресс -- это совсем не обязательно инновации. А инновации -- совсем не обязательно новое, которое отрицает старое. Два с половиной тысячелетия назад Конфуций в главной книге конфуцианства "Лунь Юй" ("Беседы и суждения") говорил: "Тот, кто, обращаясь к старому, способен открывать новое, достоин быть учителем... В древности учились для того, чтобы совершенствовать себя. Нынче учатся для того, чтобы удивить других".

Ответ на »сообщение 2493« (Max Belugin)
___________________________

Я думаю, не всегда. Например, если сделать программу меньше она может влезть в кеш и стать бвстрее

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

Тот же Микаэль Франц в ETH Zurich решал подобную дилемму "скорость против объема", расчленяя компиляцию на две фазы (front-end и back-end) с привязкой фазы синтеза объектного кода (back-end) к стадиям динамической линковки и загрузки (кодогенерирующий загрузчик). Он обнаружил, что время, дополнительно затрачиваемое загручиком на "докомпиляцию" (с абстрактных деревьев в код целевой платформы), нивелируется за счет подгружаемого объема. Программа на диске в недокомпилированном полуфабрикате занимает существенно меньше времени, грузится быстрее, а поскольку процессорные скорости индустрия наращивает активнее быстродействия жестких дисков, происходит компенсация дополнительного времени "докомпиляции".

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

Любопытно, что для представления вещественных чисел (по крайней мере, в DrScheme) на такое не сподобились. А чего вдруг?

Любопытно, а каким это образом Вы сможете это сделать?
А попробуйте представить в двоичном виде десятичное число 0.2 или вычислить 1.0/3.0 без потери точности - хватит ли Вам  памяти размером со Вселенную? Очень интересно...
В большинстве случаев (по умолчанию) для вещественных чисел хватает 64-битного типа Double. Диапазон значений у него куда больше, чем у 64-битного LONGINT...


Тут как-то нервно начинаешь коситься на то, что в коде

fac 0 = 1
fac n = (n-1) * fac n

с похвальной заботой повторяющем школьное определение факториала, рекурсия отнюдь не хвостовая...

Вапще-то в этот код закралась маленькая ашыпка. Вторая строка должна выглядеть так:

fac n = n * fac (n-1)

или

fac (n+1) = (n+1) * fac (n)

но суть не в этом...

То, что рекурсия не хвостовая и переполняет... С тем большим числом. которое Вы предложили (1000000000000!), никакая хвостовая рекурсия и никакой цикл не помогут...
А вообще есть трансляторы, которые способны такие простейшие формы рекурсий преобразовать в хвостовые.


Насколько я понимаю, довольно общая претензия к Оберону состоит в том, что Оберон -- "синтаксически несладкий" (диетический :) ).

Да полноте Вам! Какие претензии?
В Обероне полно синтаксического сахара, вот только для Вас он привычен - Вы давно на него подсели и он для Вас необходим, а потому и сахаром не кажется...

Ответ на »сообщение 2492« (Руслан Богатырев)
___________________________
... если будешь стараться...
90% на сегодня ничем себе не ограничивают достараться во до такого:

http://ru-dailywtf.livejournal.com/46502.html

МНЕ НЕ СМЕШНО.

Ответ на »сообщение 2492« (Руслан Богатырев)
___________________________
Но суть-то здесь не в том, что это весы-качели. А в том, что если будешь стараться выиграть в одном, то должен понимать, что делаешь это за счет другого. Т.е. аккуратно заоптимизировав (а не в лоб написав) по одному критерию, наверняка проиграешь по другому.
Суть - в наличие того, что выделено. А если такого старания не наличиствует в принципе? Льют, что слюна на язык принесла! "Работает же!"
По моим прикидкам, 7 из 10 (примерно) людей, которым я давал ссылку на эту ветку просто не понимают предмета обсуждения...

Ответ на »сообщение 2493« (Max Belugin)
Кэш - это уже трюки. Мы ж, вроде, про "чистый" фоннеймановский вычислитель беседу ведём? :о)

Ответ на »сообщение 2492« (Руслан Богатырев)
___________________________
Я думаю, не всегда. Например, если сделать программу меньше она может влезть в кеш и стать бвстрее