Re: [stack] stOck

> In the case of a stack, the data are stored in such a structure
> that it requires juggling in addition to operations that well
> belong to the operative solution. Compare this to iteration in
> a collection: In C or Pascal you need an index only because of
> (wrong) language design.

No, it's no more WRONG than gromgramming by 'binary switches'.

>In Python you can write "for item in collection:" directly,
>in Ruby "collection.each()", in Io "collection foreach ()",
>all idioms which imo better map the model.

Yes, this is just a HIGHER level, which often is better.
If I 'program' google to:
 fetch me urls of all Usenet articles in groups *linux*
 which have the case-insensitive phrase "formal methods",

then I'm 'programming' at a rather HIGH level ?
An even higher level is to just delegate the task to
your software-engineer.

But behind the scenes [the implementation] there's
a lot of 'stack operation', because ALL tasks are solved
by decomposition, and decomposition means the subtasks
are stacked.

So because forth is low-level it gives direct access
  to the stack.
C & Pascal are higher, but acknowledge the stack nature
 by their block-structure.

Being able to write "for item in collection:"  is a yet
higher level of programming: hiding the implementation
even more, and allowing you to better mentally-model
the problem domain.  Googling is still higher.

So you are confusing the language IMPLEMENTATION with
the 'programming in the problem domain'.

The common method of solving [somewhat] the problem
which you correctly describe is to 'build a hi-level
abstraction on top of the lower-level'.

But if you've got hi-level tools that do your task
then you'd use them, rather than stack-shuffling.

OTOH in many cases 3 wheel-barrows are 'better' than
a hi-tech auto-transporter.

== Chris Glur.