 |
lua-l archive |
|
|
||
|
On Jun 7, 2012 1:24 PM, "steve donovan" <steve.j.donovan@gmail.com> wrote:
>
> On Thu, Jun 7, 2012 at 2:06 PM, joao lobato <btnfdp.lobato@gmail.com> wrote:
> > Yes, I can see why method chaining seems easier to follow when reading
> > code, but it is in contravention of [1] 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 [1], 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.
>
> [1] 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".