On Jun 7, 2012 1:24 PM, "steve donovan" <email@example.com> wrote:
> On Thu, Jun 7, 2012 at 2:06 PM, joao lobato <firstname.lastname@example.org> wrote:
> > Yes, I can see why method chaining seems easier to follow when reading
> > code, but it is in contravention of  and I don't want to be stopped
> > by the police :-) .
> Well, the Thought Police tend to work according to the letter, not the
> spirit, of the law.
> A very successful implementation pattern has been pipelining (classic
> Unix style) and method chaining works like that; one applies
> processors to a stream of data (and that data can be strict as it
> likes about sharing its secrets).
> > Things like list comprehensions, pattern matching as it exists in
> > Haskell or Erlang,
> I see them as implementation patterns , not for composing large
> software systems. Modules should still be minimally coupled, and do
> their one thing well. We would all agree that a module that mixes
> database management and GUI generation is ripe for refactoring.
> steve d.
>  A list comprehension (for instance) translates into a for-loop
> anyway; why does it then become a less useful screwdriver, or more
> dangerous than a for-loop?
You can't break out of that for-loop. Those kind of constraints shape your solutions in ways that can easily make them suboptimal both in time/memory and ease of reading.
It's relatively easy for a regex to be harder to read then the underlying grammar would be in BNF, for example. And you'd be limiting yourself to pseudo-regular grammars with different kinds of "frosting".