Re^5: How to understand chapter 6 of Higher Order Perl?

[DrHyde]

It is difficult to learn if you're only used to programming in an imperative style, but it's worth persevering. I sometimes found that some bits only really made sense to me if I skipped over the chapter, saw how it was used in practice, and then came back for the explanation.

As for not using it - I rarely programme in an entirely functional style, but I learned a huge amount from HOP that I find incredibly useful every day, both in my fun-time programming and at work. There are some problems where it's really useful to be able to construct functions on the fly which are variations on a template, and to throw functions around as data. Sure, you can always find other ways of doing it, but the functional way is easier to read and debug.

[Laurent_R]

I learned a huge amount from HOP that I find incredibly useful every day, both in my fun-time programming and at work. There are some problems where it's really useful to be able to construct functions on the fly which are variations on a template, and to throw functions around as data.

I could not agree more. I could have written almost exactly the same sentences, this is exactly what I think. I would just add one more thing: even though I have been using functional languages at college in the past (and found them interesting but not very useful in real life programming - I was probably wrong on this last point, but that's how I perceived it at the time), I had never really seen how these concepts could be utilized in a very useful manner in a predominantly imperative language such as Perl, until I read HOP. This book has not only changed my way of programming in Perl, but also even the way I think about programming in other languages (Perl is by far my favorite language and the one I am using the most, but I have to use regularly more than half a dozen other languages, such as shell, C, C++, awk, Java, PL/SQL, VMS DCL (the equivalent of shell under the VMS OS) and two or three database-specific proprietary languages). HOP is definitely the best book (well, or at least one of the best two books) about programming that I have read in the last 10 years. OK, some examples in HOP might be contrived, but I think it is just because the author, MJD, is just trying to make the spectrum of possibilities as large as possible. It is up to you to use what you like and discard what you don't like.

[BrowserUk]

OK, some examples in HOP might be contrived, but I think it is just because the author, MJD, is just trying to make the spectrum of possibilities as large as possible. It is up to you to use what you like and discard what you don't like.

There is (at least) one problem with that perspective:

Were the HOP examples written in any language that supported either: compile-time in-lining: or runtime JIT: then the abstractions that HOP uses would be trivially inconsequential to the real-world effectiveness of the solutions it proposes.

They aren't; ergo: it isn't.

No one with any real experience of using Perl to solve real-world, real-time, (ie. just 'real') problems; would propose/advocate using such tortuously incestuous, blatantly suboptimal, O'Woe solutions to such trivial problems as exampled in HOP.

As impressive as HOP appears to so many; there is no example in it that cannot be better -- more clearly; more maintainable; more efficiently -- coded in (real) Perl; rather than in its peculiar brand of Haskell-pretending-to-be-Lisp, trans-coded to Perl.

If you attempt to speak Dutch; or Russian; or Mandarin Chinese; whilst thinking and phrasing in English; the result is a grossly verbose, and ultimately, unintelligible mess.

Ditto, attempting to write Lispish Haskell using Perlish syntax.