Summary of HigherOrderFunctions examples and scenarios given on this wiki, most of which relates to the applicability of HOF's to custom business applications (CBA, see CustomBusinessApplicationDefinition).
SummaryOfHofExamplesTwo will try a different approach to summarizing.
Weather analysis system in ArrayDeletionExample.
- Cons:
- Author says it's covered by a non-disclosure agreement, limiting questions and further probing into the business logic.
- May not be a CBA
Multi-panel auto-refresh display (A.K.A. "Brady Bunch Intro") as found in
ArrayDeletionExample:
- Pros:
- Cons:
- Assumes one is stuck using JS/DOM, which only has one kind of built in "timer", and it requires HOF's as input unless one rolls their own timeer. Thus, the "benefits" of HOF's are only specific the particular client. It's comparable to saying it's easier to use the TutorialDee query language on the RelProject than on an SQL-based RDBMS. A UI "timer" does not have to inherently depend on HOF's in its interface. VB classic had one that did not "expose" or require HOF's, for example.
- If you feel the environment unrealistically forces HOFs to be used -- and counter that with an imaginary environment that doesn't require HOFs -- then why not imagine your imaginary environment a step further, to wit: "No matter what your requirement is, there is already an existing application that does it. Therefore, HOFs are never needed." (Indeed, by the same logic, we never need any programming!) Obviously, this is absurd reasoning; we can't consider imaginary tools when examining real applications. If we're going to consider real applications rather than abstractions, we have to accept the real requirements and real conditions that the real environments impose.
- Discussion continued at HofExamplesDiscussionTwo.
- NodeJsAndHofDiscussionTwo discusses an OOP pseudo-code version.
App-side joins and unions from tables in different databases could benefit from the app querying both databases at the same time.
(Example found in
NodeJsAndHofDiscussion)
- Cons:
- Ideally the language should have a "parallel" block construct in my opinion for that kind of need. (Such blocks are not common in most mainstream languages.) HOF's would be more useful if we needed to dynamically create parallel processes/threads (or at least variations of concurrency), but decent scenarios for that haven't appeared outside of GUI tools and could be done semi-declaratively in a GUI tool, which could roughly resemble HTML "frames" and "iframes" where each panel is treated like an independent mini browser window or mini-web-app, or done via OOP.
- It has been argued that a "parallel block" is limited and inflexible compared to HOF's or NodeJS and therefore HOF's or NodeJS should be used instead. Personally, I don't understand this "in for a penny, in for a pound" argument. Parallel blocks may not be the swiss-army-knife of concurrency management, but they are relatively simple and easy to grok by a wide variety of staff, and thus is the best tool for occasional usage. Spend conceptual complexity on common things, not rare things. -t
- [Why spend effort and brainspace learning how to use a "parallel" block construct, which is only ever useful for implementing one specific pattern of concurrency, instead of learning how to use higher-order functions, which can be used both for that concurrency pattern, for dozens of others, and for completely separate uses such as InternalIterators? Spend conceptual complexity on common things, not rare things. -DavidMcLean?]
- If that "one specific pattern" is almost all the app-code-side parallelism a given shop will need, then it's the more economical choice. (Remember, the web server and RDBMS take care of most of such already.)
- [Perhaps, if parallelism is all we need in the application. What happens when we find we can use an InternalIterator too? Maybe an EmbeddedDomainSpecificLanguage or two? Event handlers? An algorithm we need to inject customisation into? What happens when we need all of those things, yet we only know about a "parallel" block construct? -DavidMcLean?]
- Continued at HofsAndEmbeddedDslDiscussion, since this is intended to be a summary.
HofPattern
- Pros:
- Cons:
- The illustration is abstract and generic rather than concrete and specific.
- Hasn't been shown applied to realistic custom business examples (disputed, as usual).
BlocksInRuby including Enumerable as described in TopOnAbstraction
- Pros:
- Enumerable provides a generic interface to all collections, including database recordsets.
- Cons:
- May be better served with objects instead of introducing yet another language construct.
- May encourage non-standard or bastardized collection handling. It may be best to hard-wire them into the language to prevent unnecessary creativity as described in StandardToolDependancy.
- [Counter-con: Doesn't do that, for reasons already described in TopOnAbstraction. -DavidMcLean?]
- I disagreed with the claims made
- [Yes. You raised a couple of concerns; you didn't make any response to my addressing those concerns, though.]
- I have to disagree with that.
- [Why? Do you have further concerns arising from my responses? Feel free to voice them.]
- I'm satisfied with my responses as-is. I feel you are just re-inventing the dead Lisp War.
- [I see you have gone on to add further responses. Thank you.]
- (Eventually expanded into DatabaseAbstractInterfaceDiscussion)
ChallengeSixVersusFpDiscussion - Reporting system with downloadable source code.
- Cons: FP proponents couldn't find a way to improve it with FP or HOF's.
- Counter-cons: Endless quarrels make it impossible to tell if it's actually the case that FP proponents couldn't find a way to improve it with FP or HOFs, or if Top simply refused to acknowledge their success.
- I don't understand, I gave runnable code for it. I don't see anything remotely close on the other side. Any "success" is purely anecdotal. If you find such, please do link to it. I want to see the metrics and how they were scored. --top
- Update: See ChallengeSixLispVersionDiscussion. The usual disputes about staffing economics and reader WetWare came into play.
PayrollExample - A basic payroll system with downloadable source code.
- Cons: FP proponents couldn't find a way to improve it with FP or HOF's.
- Counter-cons: Endless quarrels make it impossible to tell if it's actually the case that FP proponents couldn't find a way to improve it with FP or HOFs, or if Top simply refused to acknowledge their success.
- (This is not the place to complain about "endless quarrels". Evaluate topical arguments, not writing style here please.)
Employee shift scheduling
- (Illustration still under construction)
- Con: May not be CBA because 13 off-the-shelf products were found that already exist to do it.
- Counter-con: It may not make a difference in terms of code design
- Counter: Commoditization ability may imply certain patterns in the app that affects HOF's differently
- Counter-counter: The evidence for that is speculative
- Con: Claimer admitted that those products didn't exist at the time, and if they did, it may have affected the build-versus-buy decision, meaning it may not currently be CBA.
- Counter: Eventually, everything that is currently "CBA" will either be already written or available off-the-shelf, so it's not clear why that's raised as a concern here.
Custom Collating (typically for sorting)
Query-Language-Like Interface to In-Memory Structures
- See PageAnchor RAM-Structure-Query in CustomCollationOrder
- Suggestions considered but not yet fully explored: Use an RDBMS, built-in language TOP capability, OOP "override" interface, and EVAL'd expression passing.
Techniques competitive with HOF's (Depending on situation)
ObjectOrientedProgramming (presumably FunctorObjects? [1])
- Pro:
- Can attach attributes to context without changing existing calls.
- Cleaner "block" syntax. HOF's make for syntactically and visually sloppy blocks because they are often nested in function calls, which is reverse of the typical nesting structure. However, both depend on language design and it's difficult to compare without considering language features and syntax, often leading the debate into language and syntax design.
- Counter: Regarding nested functions as "syntactically and visually sloppy" is either personal preference or due to lack of familiarity with such constructs.
- Counter-counter: Re: "lack of familiarity". The fact that it's unfamiliar should count against it. I suggest the industry focus on making OOP syntax and constructs more flexible and/or powerful so that developers can leverage what they already know rather than have to deal with 2 different kinds of syntax/idioms. -t
- Counter-counter-counter: If we'd treated "lack of familiarity" as a justification for avoiding constructs throughout the history of computing, we'd have no ObjectOriented programming, no StructuredProgramming, no HighLevel languages, no AssemblyLanguage, no MachineCode, no computers, and probably no electricity.
- Typically research labs, pilot projects, or intentionally high-risk/high-reward start-ups test new ideas and tools, not mainstream production shops. That's not their job nor their forte. This topic is not about research or new-tool testing, at least that's my working assumption. -t
- Of course, but every "new idea" I listed in "counter-counter-counter" is a mainstream tool used by mainstream production shops. New ideas become mainstream ideas, or at least generally-recognised or generally-recognisable ideas. Given that HigherOrderFunctions have been available in at least one programming language since the late 1950s, and are found in a lot of languages since the 1990s, and are now available in all the top mainstream general-purpose programming languages like Python, PHP, C#, Java and C++, they can hardly be called a new idea.
- I think we're getting off track here. The "lack of familiarity" was considered from a local scope: what a given typical shop can expect, at least in typical shops I have encountered over the years. From a training/hiring economic perspective of a given shop, it's my judgement that leveraging and maximizing OOP would often be the better option than introducing lambda's and HOF's. (Unfortunately, OO-limited languages may not provide enough options such that L/H's may indeed appear to be the least evil of short-term choices.) Whether typical developers "should" know X is a different scope and different debate.
- It's not a question of what developers "should" know, but what they will inevitably know -- if not now, certainly in a few years when the latest crop of tech school programming and university ComputerScience graduates hit the job market in force. Programming practice evolves. Not that long ago, OO was unknown in "typical shops"; now it's ubiquitous. Before that, it was StructuredProgramming. Of course, OO (and StructuredProgramming, to a lesser degree) was a whole new paradigm, requiring significant changes to programming practice. For many, it meant re-learning programming. HigherOrderFunctions and LambdaExpressions are just variants on already-familiar functions. They require no paradigm shift, no significant change in programming practice, no re-learning programming. For programmers unfamiliar with them, an hour or two of minimal effort -- at most -- makes them familiar.
- My Chrystal ball gives a different answer than yours. OO wasn't easy for the industry to swallow (and it's still being being evaluated and absorbed), but since it's "installed" already, the industry may just figure out it's better to leverage it for "code-block indirection" more than by throwing FP into the mix.
- The above is moving to OopVersusFpDiscussion in order to keep this summary a summary.
- Cons:
- Generally more verbose, although this may depend on the language and/or API design. It's difficult to compare without considering language features and syntax.
- HOF's may be better as work-arounds or band-aids to poorly-designed languages and/or API's. See NodeJsAndHofGuiDiscussion for more.
- Examples of comparison: Button-click GUI events: NodeJsAndHofGuiDiscussion (Example 8462 in particular) and a timer interface: NodeJsAndHofDiscussionTwo
- See also: FunctorVsClosure
EVAL: Strings of functions/expressions that use an Eval() operation when needed
- Pros:
- Their string nature means they can be changed on and stored in databases, text files, etc.
- Cons:
- Slower run-time due to parsing step
- Subject to injection attacks. (Related: PowerfulCodeEvalDiscussion)
- No compile-time checking (if using a compiled language)
- Scoping of parameters or the equivalent potentially more difficult to manage (although may depend on language features).
SQL expressions
- Pro: Complex solutions can be expressed declaratively.
- Con: Not as full-featured as HOF's or the above.
- Con: More subject to injection attacks
- Con: Requires a SQL parser, typically a DBMS.
- See also: CustomCollationOrder
CASE statements or conditionals
- Pros:
- Uses wide-spread and common language features, making it easy for beginners to understand
- Can see adjacent expressions to help identify similarities for potential refactoring
- Cons:
- May result in more components needing a recompile in compiled languages
- The grouping may not be appropriate for some applications.
- Only addresses a limited subset of HOF functionality
It's not clear how these techniques represent alternatives to HOFs. I presume "objects" means FunctorObjects, but that's just a guess. It would be useful to see code examples for each alternative that demonstrates how the alternative compares to an equivalent use of a HigherOrderFunction and/or LambdaExpression. FunctorVsClosure demonstrates the difference between FunctorObjects and LambdaExpressions in Java. It would be good to see similar comparisons for EVAL, SQL expressions, and CASE statements or conditionals.
They are not necessarily all replacements for all HOF's in all circumstances. ItDepends on the design etc.
Footnotes
[1] I'm not prepared to subscribe to further OOP or OOP-related classification here. I'd rather move the suggestion below. -t
CategoryFunctionalProgramming, CategoryExample
FebruaryThirteen
Summary Of Hof Examples