Re: Map and filter without intermediate tables

[steve donovan <steve.j.donovan@...>]

On Fri, Jun 8, 2012 at 1:34 AM, Jay Carlson <nop@nop.com> wrote:
> I think the aesthetic argument is that code should be written vertically, not horizontally,

I can buy that, mostly.  But Peter's point is that every loop needs to
be parsed by the programmer, to find any gotchas. Whereas if I see a
map() method I know precisely what the output is, that it has the same
length, etc.[1]

I used to have arguments with C++ programmers and insisted that
FOR(i,N) was better than for(int i = 0; i < N; i++) since (a) less
error prone (little j looks just like little i!) and (b) can be safely
read as a single 'word' of the source. But the animus against macros
is very strong in C++ and these days I prefer C, where you can do what
you like without worrying about the std::police.

>. In contrast, "expr:foo():bar():baz()" allows each chained function to change the identity being worked on. (It also requires that
> participants in the chain return something useful to chain off of.)

With Unix pipelines, we do have the guarantee that it's 'just text',
although Powershell makes it 'any object' and some have suggested a
shell infrastructure where the basic data format is JSON.

So I guess the point is that  "expr:foo():bar():baz()" is not
immediately recognized as "local e = expr; e:foo() e:bar() e:baz()"
and we're back to the poor sod having to stop and examine things.

steve d.

[1] in pl.tablex and pl.List, map() guarantees this by using false as
a placeholder, if the map function should return nil. Not ideal, but
not too surprising.