Roshan James
3/14/2005 8:08:00 AM
// From: William Morgan [mailto:wmorgan@masanjin.net]
// I think you might be overlooking the obvious, which is that
// you can take this approach in Ruby. You're writing the
// objects that do the computations, right? Simply give them
// #next? and #next methods and use a while loop. That's what
// you'd be doing in these other languages.
The C# and Py examples actually abstract the details of the objects that
they generate from the user. Programmers don't explicitely create these
classes. In the C# world, most people don't know that there is an
intermediate object involved even.
//
// The prevalence of internal iterators in Ruby's API is simply
// a reflection of the fact that they're so nice to use. It's
// not the only way to iterate.
Completely agree William,
The problem as I find it is one of language design - what are the
abstractions that the language gives us to make this possible? Can I
wrap continuations or create classes that manage state by hand to do
iteration? Yes I can. But that's not the problem here.
Let me quote from the pragmatic programmers guide -
<quote>
Our job is to solve problems, not spoonfeed compilers, so we like
dynamic languages that adapt to us, without arbitrary, rigid rules. We
need clarity so we can communicate using our code. We value conciseness
and the ability to express a requirement in code accurately and
efficiently. The less code we write, the less that can go wrong. (And
our wrists and fingers are thankful, too.)
We want to be as productive as possible, so we want our code to run the
first time; time spent in the debugger is time stolen from the
development clock. It also helps if we can try out code as we edit it;
if you have to wait for a 2-hour make cycle, you may as well be using
punch cards and submitting your work for batch compilation.
We want a language that works at a high level of abstraction. The higher
level the language, the less time we spend translating our requirements
into code.
</quote>
When I code in a language I wish it would give me the right
abstractions, so that I can work directly on the problem at hand.
Luke,
Thanks for the continuations implementation - the only problem
with the approach is that the Ruby interpreter there is also paying the
cost of maintaining state of the iterator. The continuation does that
further, only so we can decopule the syntactic dependancy of an iterator
and its block of code into an explicit function call (next).
The problem here IMHO is with language design and it is solved by usage
of expensive language contructs. Today if I have to solve the problem I
would go ahead and use generators - I am hoping that the language does
something better for the future.
Cheers,
Roshan