Ленивое программирование и ленивые вычисления

боянище !

щас ещё пионэры прибегут

Хоть и не программирую читать было интересно.

let the war begin!

Вот что интересно: начал осваивать Scheme - и понеслось, сначала Sun-ch в толксах про Лисп, теперь тут ... =)

> Вот что интересно: начал осваивать Scheme

А почему не Common Lisp? Просто интересно, чем обусловлен выбор?..

Не было процедуры выбора. Узнал - попробовал - понравилось.

> А почему не Common Lisp? Просто интересно, чем обусловлен выбор?

Для освоения схемка заметно проще -- сильно меньше сущностей. После схемы перейти на cl совсем несложно, надо только привыкнуть к постоянным funcall'ам ;)

Это, вроде, называется "динамическое программирование", нет?

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

> Для освоения схемка заметно проще -- сильно меньше сущностей. После схемы перейти на cl совсем несложно, надо только привыкнуть к постоянным funcall'ам ;)

Понятно. Сам-то грызу гранит CL, но было такое ощущение, что в беглом знакомстве с фичами Scheme упустил из вида что-то значимое.

> Не было процедуры выбора. Узнал - попробовал - понравилось.

Хммм... А я сделал apt-cache search common lisp и то же самое для scheme, почесал затылок, сделал выбор %)

$ apt-cache search scheme | wc -l
210
$ apt-cache search common lisp | wc -l
193

:)

>Это, вроде, называется "динамическое программирование", нет?

>динамическое программирование полезно, если на разных путях встречаются одни и те же подзадачи. основной техн. прием -- запоминать решения встречающихся подзадач на случай, если та же подзадача встретится вновь.

нет, это не динамическое программирование.

я люблю ibm за замечательные статьи на своём сайте да и на русском!!!!!!!
РЕспект.
ПС сам люблю больше python, ленивые вычисления в нём тоже есть.

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

Хочу пример ленивых вычислений в python...

Давайте постить каждую главу SICP в новости.

А чего бы и нет? :)

Интересная статья.

Сначала подумал, что ленивые вычисления можно реализовать и на не ОО языке. Но потом понял, что это подходит только для функций, у которых нет аргументов.

Такое ощущение, что в императивных языках ленивые вычисления похожи на костыль.

И мы возвращаемся к десятому правилу Гринспуна.

P.S. Сам функциональные языки не осилил пока.

есть похожая хрень в виде либы для "полуязыка" С++ (на другую половину он "полуассемблер", в нормальном языке указатели как низкоуровневое средство доступа к памяти вредны ;) ): http://sourceforge.net/projects/atoqu/

в той версии есть небольшой мемори лик (когда связь удаляется), а новую версию с багфиксом мне выкладывать лень, поддержку тредов пока не допилил, программирование-то ленивое ;)

> Сначала подумал, что ленивые вычисления можно реализовать и на не ОО языке

Это утверждение вообще говоря некорректно. В языке долны быть либо замыкания или способы их имитации.

Главная засада ленивости - нет никакой внятной теории, которая давала бы оценку времени выполнения ленивого алгоритма (см. Окасаки).

Смешно, оценил

> Это утверждение вообще говоря некорректно. В языке долны быть либо замыкания или способы их имитации.

В статье есть пример кода на Java, но взглянув на количество кода, которое необходимо для этого, сразу что-то и не хочется с этим возиться.

ИМХО в неленивых языках такая излишняя оптимизация может плохо сказаться на доступности кода другим программистам.

>Такое ощущение, что в императивных языках ленивые вычисления похожи на костыль. >И мы возвращаемся к десятому правилу Гринспуна.

А можно ссылочку на Гриншпуна?

>Это, вроде, называется "динамическое программирование", нет?

не то. lazy evaluation ещё называется call by name - если известно, где можно гарантировано получить значение, то зачем кидаться его обсчитывать? большенство компиляторов действуют по принципу call by value.

http://philip.greenspun.com/research/

А вам не кажется, что наиболее адекватный перевод данного термина - отложенные вычисления?

>А можно ссылочку на Гриншпуна?

http://en.wikipedia.org/wiki/Greenspun's_Tenth_Rule

Термин "ленивые", может, и не самый удачный, но уже давно устоявшийся.

> А вам не кажется, что наиболее адекватный перевод данного термина - отложенные вычисления?

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

не прошло и ста лет, как народ начал осознавать, что языки, которые считались академическими, дают возможность эффективно реализовывать программные продукты.

судя по частоте сообщений в lispjobs, интерес становится все больше

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

http://en.wikipedia.org/wiki/Lazy_evaluation

computer programming, lazy evaluation, also called >delayed evaluation<,

>Что такое ленивые вычисления - это когда программа тормозит не по-децки или не хочет делать то, что ей говорят?

Нет. Это аццкая машынка, про которую не знаешь, когда она рванёт. Ж)

В общем, уверенности не прибавляет.

Ленивое программирование - это я знаю, это пыхпых, дельфи и жаба. А ленивые вычисления - это чё, перемножение матриц на питоне?

> обобщенное понятие для отсрочки обработки функции или запроса до тех пор, пока не понадобятся результаты.

А разве это не задача оптимизирующего компилятора?

> Хочу пример ленивых вычислений в python...

http://freshmeat.net/projects/lazypy/

Подход имеет чисто теоретический интерес.

Не дай бог таким образом писать программы расчитанные на более чем 1 запуск....

В этом смысле и Питон вреден.

А уж Schema эжто просто форменное издевательство над разумом. Таким людям за вредность доплачивать надо, если работодатель такие извращения требует.

> нo взглянyв нa кoличecтвo кoдa, кoтopoe нeoбxoдимo для этoгo,

Дык макросов нету, вот и приходится руками код вбивать. Быдложаба она такая.

> A paзвe этo нe зaдaчa oптимизиpyющeгo кoмпилятopa?

Нет.

> удя по частоте сообщений в lispjobs

Ждём лиспобыдлокодеров? =)

Странно всё это, я например вызываю функции, когда мне СРОЧНО нужен их результат.

Старею...

1. в Python операторы or и and являются ленивыми.
2. Генераторы достаточно мощный инструмент для написания различных структур ленивых вычислений.
3. Ленивые вычисления - http://ru.wikipedia.org/wiki/Ленивые_вычисления просто другое название для этой темы.

Да и совсем забыл(цитата с википедии):
Python &#8212; имеет возможность создавать ленивые определения с помощью ключевого слова lambda.

как говорится - "Слона то и не заметил."

Реально лениво это все комментировать

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

Важно не только правильно перевести термин, но и перевести его так, чтобы он звучал привычно и не "резал ухо". "Ленивые вычисления" звучит непривычно и в общем случае требует разъяснения, "отложенные вычисления" - нет.

Видимо дело ещё и в традициях. У них принята несерьёзность в названиях, у нас - нет.

>имплементация

Задолбало!! >E Автор перевода видимо не знает как это на русский переводится?

Текст этого комментария будет сгенерирован в момент обращения к нему.

> Видимо дело ещё и в традициях. У них принята несерьёзность в названиях, у нас - нет.

Вот эта наша пустая напыщенность мне и не нравится...

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