[Tutor] Text processing and functional programming?

Alan Gauld alan.gauld at blueyonder.co.uk
Wed Aug 13 09:48:00 EDT 2003


> You know, I picked up that book expecting to love it (almost
everything I do
> involves processing text in some way or other), but after reading at
Ch 1, I
> mostly learned that functional programming is a way of making Python
look
> like Perl.

I reviewed Mertz' book and one of my comments was that he needed
to expand the explanation of FP because even intermediate Python
programmers often avoid the FP stuff. In response the explanation
did almost double. But the point remains that FP is foreign
territory to many programmers.

> My impression is that lambda and map/filter/reduce can often be
replaced by
> list comprehensions. Is this correct?

Often, not always. And comprehensions are confusing in themselves
(although powerful) and 'filter' or 'map' is a much more descriptive
term for whats going on. Unfortunately FP is heavily geared toward
those with a formal math training, particularly those who have
studied predicate logic and the lambda calculus. If you haven't
(and that means most of us!) then FP can seem extremely arcane.

> > This explicit looping approach works, but it mixes together
applying a
> > function across a sequence with finding the minimum of the
sequence.
> > There's more potential for programmer error with this approach.
>
> I'm skeptical about this.

You shouldn't be, its based on many years of study and data
collection.
One of the definite advantages of FP is that it leads to more reliable
(note this is different from easy to debug!) code because it removes
complexity (in the CS sense not the human eye sense).

What that means is that given a programmer who is as fluent in FP as
in imperitive programming, his FP code will contain fewer errors.

> This assumes that most programmer error comes from
> writing rather than maintaining code.

No, actually it assumes most error comes in the translation
from design to source code. "Off by one" index errors etc.
Again thats based on empirical studies into the nature of
software faults.

> From looking at TPiP, it looks to me like FP takes some basically
sensible
> ideas -- the easiest loop to debug is the loop you don't write,
nested
> transformations can make the operations on an object clear -- and
makes them
> cardinal virtues, at the risk of losing things like readability and
obvious
> flow.

That's a pretty good summary. It is more demanding of the programmer
but
offers, in return, shorter code, more error free code and often more
performant code. But its harder for the non expert to read and
maintain
and often a nighmare to debug with conventional tools.

Alan G
Author of the Learn to Program web tutor
http://www.freenetpages.co.uk/hp/alan.gauld




More information about the Tutor mailing list