On Tuesday, 28 August 2012 at 22:53:46 UTC, bearophile wrote:
The purpose of this post of mine is to compare a nice looking
Haskell solution of this problem to its Python/D translation.
This means this post is about language design matters and it's
not about problem solving :-)
...
There is a significant problem:
- This program generates a small sequence of solutions, so
lazyness is not important. But sometimes the algoritms have to
generate tons of things, and lazyness becomes useful. This D
program is not lazy, unlike the Haskell and Python programs.
Writing this program with lazyness is not too much hard, but
the code becomes uglier, longer and more bug prone. I think C#
designers did the right thing adding yield to their language,
because it's a construct very often useful.
In general, it is not possible to have both full expressiveness
and full performance. D gains most of its performance by early
binding as much as possible. You can delay binding by using the
InputRange!T interfaces in D to get a similar level of
expressiveness as in Haskell or Python, but you lose some
performance.
Yield is interesting, a nice way of turning an algorithm into a
data structure. However, I imagine it would be very tricky to
implement in D with various lifetime issues, although maybe I'm
wrong. What I do know is that it is far too big a feature to be
adding at this stage in D2.
