Глядя, как бодаются gaperton с thesz, лулзов ради решил создать темку.

Речь идёт о модели вычислений в языке программирования. Ленивость по умолчанию или строгость (strictness) с явными аннотациями ленивости.

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

Fight!

И тишина, и мёртвые с косами стоят.

ктоэта?
вообще, ленивые вычисления возможны не только в Haskell, только там они ленивые все и по умолчанию, так?
если да, то я считаю что это должно плохо сказываться на производительности а так-же на предсказуемости работы программы 

%username% @ ЖЖ и RSDN

Какбэ да.


У меня, кстати, осмысленной позиции по этому поводу нет, потому что на Haskell я практически не писал, а ленивость использовал в основном в виде lazy streams, которые более или менее реализуются во всех приличных языках.

вот вам ленивость по умолчанию. 



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

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


но когда и в каком порядке никто заранее не знает

в общем я так понимаю ленивость
допустим есть у нас цикл

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

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

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



почему же? есть два аспекта:
1. современные компьютеры (в большинстве) архитектурно императивны. и моделируя другие парадигмы появляются доп. накладные расходы
2. для не императивной модели затруднена оптимизация кода

рассмотрим:
1. a) опытный программист знает как устроена виртуальная машина, производящяя вычисления. и может это учесть.
    б) собственно вычисления часто составляют не такую уж большую часть программы. многое зависит от эффективности используемых библиотек. недаром Java, исполняемая на VM, часто не уступает в скорости С++ на реальных приложениях
    в) любое инженерное решение имеет достоинства и недостатки. это из разряда, когда за эффективность разработки мы платим некоторым снижением производительности

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

однако все это не вполне относится к ленивым вычислениям. например:


vs

во втором случае неизвестно, вызовется ли get_b(), но здесь не меньше, а, может, и больше возможностей для оптимизации.

что касается языков с ЛВ, то здесь имеем оптимизация графа vs "лишние" переменные. что эффективней - зависит от программы и программиста.
кстати, про сборку мусора и проч. наличие доп. переменной само по себе на производительность не влияет: память тратится, но и почти все. эффективное управление памятью - неотъемлемая часть реализации функционального языка, но распределение памяти там происходит под управлением исполняющей системы, а не так бардачно, как, скажем, в Java. Так что все не так плохо 

Добавлено через 7 минут и 46 секунд
что касается вопроса темы - подход к ЛВ от точки зрения зависит, которая формируется под влиянием используемого языка. В каждом языке свои походы и приемы, однозначно сказать что лучше нельзя. имхо.