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

Я свидетель, когда эти "качели" нарушались в обе стороны! И памяти вагон хапнули и алгоритм самый медленный из тех, что можно было выдумать! :о))))

Но суть-то здесь не в том, что это весы-качели. А в том, что если будешь стараться выиграть в одном, то должен понимать, что делаешь это за счет другого. Т.е. аккуратно заоптимизировав (а не в лоб написав) по одному критерию, наверняка проиграешь по другому.

Если кому интересно, в этой записи блога Чарльза Калверта - ссылка на видео с его интервью с Андерсом Хейльсбергом, где тот говорит о LINQ и функциональном программировании.
http://blogs.msdn.com/charlie/archive/2007/01/26/anders-hejlsberg-on-linq-and-functional-programming.aspx

Ответ на »сообщение 2489« (Руслан Богатырев)
___________________________
Проф. Bruno Thuering в 1950-х годах сформулировал закон взаимной зависимости (Reciprocity Law of Programming): экономия в объеме подразумевает потери во времени, экономия во времени подразумевает потери в объеме. Закон, похоже, фундаментальный.
Я свидетель, когда эти "качели" нарушались в обе стороны! И памяти вагон хапнули и алгоритм самый медленный из тех, что можно было выдумать! :о))))

В отношении обсуждавшейся здесь компактности записи ФП-программ по отношению к ИП-программам.

Компактность записи исходного текста -- палка о двух концах. Вспоминается исследовательская работа Лутца Прехельта (ныне -- профессора Берлинского университета, Freie Universitat Berlin) "Эмпирическое сравнение семи языков программирования" (2000) -- http://www.osp.ru/os/2000/12/178361/
Когда он проводил исследование (1997-1998), то был по другую сторону баррикад -- работал руководителем службы контроля качества немецкой компании abaXX Technology.

Среди полученных им выводов:
1. Проектирование и составление программ на языках Perl, Python, Rexx и Tcl занимает не более половины времени, необходимого для программирования на Си, C++ и Java -- а длина исходного текста вдвое меньше.
2. Типичный сценарий (скрипт) занимает примерно вдвое больше памяти, чем программа на Си или С++. Программы на Java занимают втрое и вчетверо больше памяти, чем программы на Си и С++.

Прехельт подтвердил правило инвариантности производительности программиста -- в единицу времени одинаковое число строк вне зависимости от языка. В основу данной проверки положено старое практическое правило, согласно которому число строк исходного текста, выдаваемых программистом в час, не зависит от языка программирования. В нескольких широко применяемых методах оценки трудозатрат -- в том числе Cocomo Барри Боэма и таблицах языков программирования для оценки функциональных точек Кейперса Джонса -- явно предполагается, что почасовое число строк исходного текста не зависит от языка программирования... Судя по достоверно известному диапазону продуктивности при работе с Java, все величины, за исключением трех лучших результатов для Tcl и лучших времен для Perl, выглядят правдоподобно.

Итак, синтаксическая компактность записи (writeability) экономит время. Но какое время? Время синтеза, но не анализа. Для одноразовых, короткоживущих и неотчуждаемых от автора вещей компактность видимо более важна, чем readability (наглядность; это уже отмечал, когда писал про тендер Минобороны по Аде -- см. сообщение 3473 в ветке по Оберону). Но для отчуждаемых и долгоживущих, активно сопровождаемых и допускающих легкость внесения изменений в чужой код? Вспоминается случай из практики, когда решил сделать свертку IF-ов по вычислению вспомогательного индекса для кнопок в меню. За полчаса нашел искомую формулу. Очень обрадовался, а когда спустя полгода понадобилось корректировать, вернулся к своему же исходнику и стал с трудом вспоминать, что тут тогда намудрил. Как к ней пришел. С тех пор стараюсь трансформировать текст с учетом разных факторов, а не одной лишь компактности.

Проф. Bruno Thuering в 1950-х годах сформулировал закон взаимной зависимости (Reciprocity Law of Programming): экономия в объеме подразумевает потери во времени, экономия во времени подразумевает потери в объеме. Закон, похоже, фундаментальный.

Ответ на »сообщение 2476« (Илья Ермаков)
___________________________

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

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

Ответ на »сообщение 2484« (AVC)
___________________________
Но в целом идея о том, чтобы полностью "спрятать" устройство машины от школьников, мне по-прежнему кажется сомнительной.
Мне тоже. Здесь всплывает вопрос о целях преподавания программирования в школе. На мой взгляд в обучении имеет смысл не спрятать проблемы арифметики больших чисел, а показать их. Имхо гораздо интереснее не просто вычислить на мощном калькуляторе 100!, а разобраться, каким образом можно организовать такие вычисления. Тем же, кому это не нужно, подозреваю, что и сами такие вычисления будут не слишком нужны (речь идет о школьниках и преподавании информатики) .
Кстати говоря всё преимущество примера вычисления факториала  - не в особенностях функциональных языков, а во встроенном целом типе произвольной длины, что есть например и в Python'е. Ну и тут еще играют роль динамические типы данных (при вводе-выводе допустим, если взять пример Geniepro на Обероне)). А в остальном, на паскале факториал так же просто вычисляется через рекурсию
function Fact(n: integer): int64;
begin
  if n = 0
  then Result := 1
  else Result := n*Fact(n-1);
end;
(как и в примере с ФЯ, проверка отрицательного аргумента не проводится).

Мэйнстрим нынешний формировался американцами. Если в сфере политики и экономики  многополярный мир существовал практически до распада Советского Союза, то в сфере программирования он свелся к однополярному уже к началу 1970-х. Американцы делали несколько ознакомительных визитов в Советский Союз (особенно в конце 1950-х и начале 1960-х годов). Они подметили ключевую особенность Советов -- лицо программирования у нас определяли математики с мировым именем. Русская школа Николая Николаевича Лузина была недостижимым для Запада образцом. Лучшие же математики Америки на программирование смотрели как на что-то потустороннее. А потом не без участия Н.С.Хрущева мы похоронили свой потенциал.

Еще раз вернусь к мыслям Дейкстры. Он писал, что обучение программированию -- это не обучение языкам программирования. Курсы по языкам он скептически называл "уроками вождения". Никто не говорит студенту, что все эти мощные средства относятся больше к сфере задач (problem set), чем к сфере решений (solution set). Никто не говорит ему, что в лучшем случае он станет высококлассным кодером простейших алгоритмов и что его трудности никогда не будут возникать от самой задачи, а всегда -— от извилистости того пути, которым алгоритм (обычно уже заданный) должен быть запрограммирован.

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

То, что было 40 лет назад в Алголе-68, только-только стало повторяться в промышленных языках (таких как С#, Java).

На грабли наступили уже тогда. Было бы здорово, если бы люди делали выводы из истории, а не начинали по новой. Следует заметить, что в 1950-1970-х годах уровень проработки алгоритмов и систем был много выше, чем сейчас. Объяснение простое: мотивация была не в деньгах, люди были одержимы изучением нового, еще не изведанного, плюс с ресурсами была напряженка: 4К-64К -- это непонятно для нынешних поколений. Потому и обсасывали деталюшечки. Не было такого количества соблазнов окружающей действительности, такого моря макулатуры, из которого выделить значимое подчас трудно даже зубрам программирования. Практически все классики тесно общались друг с другом, шел интенсивный обмен идеями. Истина была важнее. Они не выступали по многу раз в свете софитов перед объективами телекамер и не растрачивали себя в различных тусовочных мероприятиях и пресс-конференциях. То было время титанов. Сейчас народ обмельчал...

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

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

Стефан Банах (банаховы пространства, думаю, многие изучали в вузе) как-то заметил:  "Математик -- это тот, кто умеет находить аналогии между утверждениями. Лучший математик -- кто устанавливает аналогии доказательств. Более сильный может заметить аналогии теорий. Но есть и такие, кто между аналогиями видит аналогии". Замените слово "математик" на "программист". Смысл и сила высказывания не изменится.

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

Не понимаю, что значит "нет малых"? Если почитать официальные сообщения о языке Haskell, то там сказано, что модуль Prelude определяет два целочисленных типа - Int и Integer. Int - это целые числа фиксированной точности, Integer - целые числа произвольной точности. Диапазон для Int определяется реализацией и может быть определен через значения minBounded и maxBounded. Насколько я понимаю, это полный аналог обычных целочисленных типов данных в "обычных" императивных языках программирования.

Если так, беру свои слова о целых и операционках назад. :)
Теперь понятно, что в предложенной Джеком реализации факториала
fac 0 = 1
fac n = (n-1) * fac n
просто кое-чего не хватает.
А я так уже привык к Схеме (где тоже есть большие целые), что не подумал о пропущенном объявлении типа.

Но в целом идея о том, чтобы полностью "спрятать" устройство машины от школьников, мне по-прежнему кажется сомнительной.
"Естественный" способ определить факториал ("понятный школьникам") может привести к переполнению стека. И т.д. и т.п.

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

А что же он Эйлером никого не убил?

Убил. Алан Кей до сих пор не может прийти в себя. И все сокрушается, почему Вирт забросил ту золотую жилу, которую нарыл в те годы.