Moved from NodeJsAndHofGuiDiscussion because discussion grew away from GUI's.

As far as "evidence", see LetReaderDecideEvidenceAgreement.

''The claim that HOFs and lambda expressions cause confusion is yours alone.  If you want "agreement", retract your claim until you have evidence to back it up.''

Again again again, evidence based on personal experience is acceptable on this wiki. I am not doing anything "wrong". I know you are personally frustrated by the lack of formal studies, but complaining repeatedly is not going to fix that. My personal observations about what confuses staff or doesn't confuse staff are just as valid as yours. -t

''Absolutely, evidence based on personal experience is reasonable.  However, whilst you have had your personal experience, we the WikiReader haven't had your personal experience.  Thus, you need to relate your personal experience in the form of anecdotes.  Merely asserting that evidence exists, but not providing it, is neither personal evidence nor rational argument.  It's just hot air.''

* It's hot-air that parsimony is the only thing that matters.

* ''Nobody said "parsimony is the only thing that matters".''

* It's implied.

* ''Maybe you inferred it, but it certainly wasn't implied.''

The default is NOT that they don't confuse developers. See near TopVsOthers on why our experience may vary. -t

''That's right.  In the absence of evidence, the default is <null>.  Whether lambdas and HOFs confuse programmers or not simply doesn't enter into the picture until there's evidence one way or the other.  Equivalently, lambdas and HOFs might cause increased energy consumption, increased memory errors, greater load on hard drives, increased global warming, premature hair loss, male impotency, and furballs in kittens.  Until any of these bad things have evidence behind them, they're irrelevant; to discuss them in the context of lambdas and HOFs would be pure speculation, and therefore a pointless waste of space, time and energy.  Likewise, until there's evidence that lambdas and HOFs confuse programmers, discussing it as if it does -- or even as if it might -- is pure speculation, and therefore a pointless waste of space, time and energy.''

That's your opinion. You WANT this to be about math and code parsimony, and ignore WetWare issues because you are smart at math and stupid at people. To bad, '''you don't make the wiki rules''' here. Fuck off, reality-detached IvoryTower fat-tuition lobbyist! The bottom line is that WetWare anecdotal evidence is allowed on this wiki.

AND, just because a factor is difficult/expensive to measure is NOT a reason to skip discussion on it. SovietShoeFactoryPrinciple.

IT'S A DAMNED FALLACY THAT PARSIMONY IS THE MOST IMPORTANT FACTOR '''JUUUUST''' BECAUSE IT'S THE EASIEST TO MEASURE!!!!! (Similar applies to other automate-able code analysis techniques.)

LetReaderDecideEvidenceAgreement is fair and reasonable, but you pissed all over it.

''A factor that is difficult/expensive to measure is certainly worthy of discussion, as long as there is evidence that it is an influential factor.  You've provided no evidence that lambdas and HOFs confuse programmers.  Anecdotal evidence is certainly allowed, but you haven't provided any.  Until you do provide evidence that lambdas and HOFs confuse programmers, there's no more point in discussing it than, say, discussing the power consumption of lambdas and HOFs or their inclination to cause furballs in kittens.''

I have too provided it. You just have an undocumented and vague personal view of what anecdote means that is probably not satisfiable by mortals. And '''if you don't want to participate in discussions that only use anecdotal evidence then leave''' the discussion rather than make your evidence preference a PersonalChoiceElevatedToMoralImperative. Your complaints about it are quite repetitive and annoying. You KEEP complaining about it over and over and over and over and over and over and over. 

Rather than repeat your complaints, SHUT UP AND LEAVE.

''No.''

''I've provided examples of anecdotes.  The only "evidence" you've provided to suggest that lambdas and HOFs confuse programmers, is your claim that lambdas and HOFs confuse programmers.  That's not an anecdote, that's not evidence, that's just stating the hypothesis.''

You did not finish your examples of acceptable anecdotes; they are too vague for me to process. It's still unclear to me what is acceptable to you. (Not that you are a standard vocab reference source anyhow.)

* ''I provided links to two pages of acceptable anecdotes, later followed by a link to a specific acceptable anecdote.  Here it is again: http://thedailywtf.com/Articles/The-Database-Gazes-Also-Into-You.aspx''

* Addressed below.

* ''Here's another one: http://thedailywtf.com/Articles/The-Data-Migration.aspx  I think it's acceptable, too.''

It is too evidence, by most accounts, and is a permissible form of evidence on this wiki. I will agree it is weak evidence, but weak evidence is all we have without formal studies being done. If you don't wish to discuss weak evidence, then don't; it's that fucking simple! '''You would rather complain than leave. I suggest you reverse that preference.'''

''Stating a hypothesis is not evidence of any kind.''

It's not merely stating a hypothesis. You are wrong.

''That's exactly what it is.  A statement of presumed truth, sans evidence, is a hypothesis.  See "science".''

Re "Database Gazes" link above, I'm still not sure how people writing bad code can be related to evidence that HOF's confuse staff. Your example said nothing about WHY the code was bad. I still see no clear connection to anything relevant.

''No specific connection is intended.  It's just an anecdote, intended to illustrate what anecdotes are like since you appear not to know.  Why the code is bad can be trivially inferred, and should be obvious.''

Anyhow, I did not write down specific events with specific code and have no such diary to present. But that does NOT make the evidence non-evidence.

If Jane Goodall stated, "I observed that gorillas get into more physical fights during high humidity." That's "evidence" by most accounts, that fight frequency is related to humidity. Weak evidence, yes, but STILL "evidence" to most humans. It's comparable to "I observe that using JS API's with more HOF's tends to stump programmers more often." I agree it would be better if Jane logged specific dates and times, specific humidity readings (from a device), number of fist movements, ID of gorillas involved, etc. But that's pulling an IwantaPony evidence level request. You are not going to get your pony from me. Weak evidence is still evidence and is allowed on this wiki. If you want to call it a "mere hypothesis" or a "fabblemoof", that's fine, but I don't have to agree to that terminology application. If you do not wish to participate in discussions with weak evidence or fabblemoof's or whatever you wish to call it, then I recommend you ignore it. If you wish to complain and THEN leave, factor your complaints into a topic and type in that topic name and then leave. Simple. Your repetitious complaining is not helping anything and makes you look a baby crying IwantaPony. Do you WANT to look like an immature stubborn repetitious spoiled brat?

{Jane Goodall, being a scientist, would very likely have done the stuff you are labeling as IwantaPony requests before she made such a claim.}

That may be true, but not relevant here. Goodall-ness personality-wise was not the key point. Hypothetically, assume she was killed before finishing her writeup and we only had that quote to work with. Most would still consider it "evidence". By the way, pay me a scientist wage, and I'll conduct FP grokking research for you and make a detailed diary with dates, times, people, code, and error messages. Goodall didn't do it for free (although may have sacrificed other more lucrative alternatives because of her love of the subject). Not only do you want a pony, but want it for free. It appears you didn't think through that snarky reply before you made it, failing to consider what brings about good research.

''Your Jane Goodall example is a StrawMan.  Given that Jane Goodall didn't make any unsupported claim like "I observed that gorillas get into more physical fights during high humidity" (before being killed, no less; as of 2014, she's alive and well), and in fact maintained notoriously meticulous notes which serve as excellent evidence, your fictional statement is the basis of a nonsensical argument.''

It was a hypothetical example, as "If" indicates. Change the name if it makes you feel better. You appear to be obstinate for the sake of obstinance.

Fental Wipperstein stated, "I observed that gorillas get into more physical fights during high humidity."

Most normal humans would consider such statement "evidence" if they heard Mr. Wipperstein state it. I don't care what your PERSONAL criteria is for "evidence". Such evidence is acceptable on THIS wiki. If you wish to change the wiki rules, DO NOT bring it up with me.

* {T:  The only way to resolve this discussion is to realize you're not conversing with a human (''hetero sapien'').  One could put him in the set called TheKooks, but he's actually a reverse-top, related to the maths.}

* ''Really?  I mean, '''really'''?  FacePalm.''

''It's not "changing wiki rules".  Such a claim is a hypothesis no matter who makes it.  In the absence of any evidence, there is no reason to regard it as anything but spurious.''

Bullshit! You always dick with English when cornered with logic. It's your weapon of last resort.

''Where do I "dick with English"?  You simply have no evidence that HOFs and lambda expressions confuse programmers, any more than HOFs and lambdas increase carbon emissions.  Why don't we argue for pages about whether lambdas and HOFs increase carbon emissions?''

Your hype blabbering over HOF's releases carbon via your hot breath. QED. 

And '''I respect the right''' of any Wikizen to propose a personally-observed relationship between HOF's and carbon. If I disagree, I'll say so OnceAndOnlyOnce and move on instead of bitch about it 3,472,027 times. YOU ARE DOING IT WRONG.

''Does that mean you'll limit your objections to OnceAndOnlyOnce the next time one of us expresses appreciation for some FunctionalProgramming or other "higher order" programming construct?''

I am not sure what you mean. If your appreciation repeats existing material, please factor it into a topic/link. Likewise I may factor my counter-criticism into a topic/link.

''What I mean is that if you can limit your disagreements about the "relationship between HOF's and carbon" to OnceAndOnlyOnce, you should be able to limit your objections to FunctionalProgramming and other "higher order" programming constructs to OnceAndOnlyOnce.''

We keep discussing new examples/scenarios (which is not a problem), but your evidence complaints fit the same OLD pattern.

{That's because your failure to supply evidence for your assertions fits the same OLD pattern.}

We disagree over what constitutes "evidence".  Further, we can LetTheReaderDecide which staffing pattern fits their own shop and apply per match such that we don't need to keep re-bickering that. If my observations don't match their shop, they can simply ignore them. Simple Dimple self-solving problem. But you don't appear satisfied with that.

''That's right, I'm not.  If you wish to use your limited "evidence" as the basis for an occasional comment that you suspect HOFs and lambdas might confuse programmers, that's fine.  However, such limited "evidence" -- which consists solely of your unsubstantiated assertion that HOFs and lambdas confuse programmers -- is certainly not justification for arguing over page after page that HOFs and lambdas should not be used.  If you don't like HOFs, lambdas, or other aspects of FunctionalProgramming, that's fine -- you can ignore the discussions about them.  The rest of us can then get on with discussing the evolution of programming without your interference.''

Re: "arguing over page after page that HOFs and lambdas should not be used. " -- That's not directly what I do. I pretty much present alternatives to HOF's '''IF''' the reader, shop, or API/language maker wants to likewise avoid them. YOU then have a fit for the mere suggestion that somebody may not love HOF's/FP and then bitch about "evidence". '''You are over-protective of your pet paradigm.''' Admit it and seek therapy. The problem is with YOU, not me.

''I don't see a lot of presenting "alternatives to HOF's" here, or anywhere else.  I see a lot of quibbling based on an undefended claim that HOFs and lambdas confuse programmers.  When you do present alternatives, the only legitimate alternative is a FunctorObject.  The other presumed alternatives are isomorphic to "write all the code differently", which is always an option but rarely an alternative.''

Your opinion is noted.

And '''what's wrong with presenting alternative designs'''/APIs/code-styles? REGARDLESS of whether there is an absolute or clear need for alternatives? Let alternatives be presented. If you personally don't want to see alternatives, then don't read them. But don't pre-filter them for every other potential reader.

''When "alternatives" reach the point of being isomorphic to "write all the code differently", it's pointless to present them.  You can '''always''' use "write all the code differently" as an alternative to anything.  For example, offering SQL as an alternative to HOFs is essentially "write your program in a different language", which applies equally to (say) FOR loops as it does to HOFs.''

Sorry, I'm not understanding your point.

''Some of your proposed "alternatives" to HOFs -- SQL, for example -- are "alternatives" to everything.  They are not specifically alternatives to HOFs.  Thus, they are no more helpful than "rewrite your program".''

I'm still not following your point. Presenting alternative implementations to specific examples is not a sin. See CategoryInManyProgrammingLanguages.

''Presenting examples that are specific enough to be useful is fine.  For example, showing how a specific HOF-based example can be replaced with equivalent SQL, or even as a general pattern, would be useful.  You merely proposed SQL as an alternative, without explanation.  That's not useful, and it's too vague to be meaningful.''

This is not the place to ask questions about examples. Please do it at the allegedly offending example page. 

''I'm not asking questions.  My comment is relevant to this discussion about alternative implementations.  If you like, feel free to move this whole threadlet to where you feel it is more appropriate.''

I don't know where the "without explanation"-ness is happening. 

''Elsewhere, you suggested SQL as an alternative to HOFs.  You didn't explain how SQL could be used as an alternative to HOFs.''

If I encounter such spots, I'll review them. It may have been related to parallelism and concurrency claims around HOF's. For example, "SELECT * FROM foo WHERE x > 7" doesn't have execute in parallel (one row at a time). The RDBMS may split up the work to multiple cores, servers, etc. -t

''They're on SummaryOfHofExamples under "Techniques competitive with HOF's."  I've added specific criticism to that page.''

-----------
Continued from IndividualExperienceShapesPerceptions.

''I recommend looking up "evidence".  A typical definition is that evidence is anything that supports an assertion.  By obvious implication, that means it isn't the assertion itself.''

Statements of such observed patterns (X tends to happen when Y is high) are often referred to as "anecdotal evidence". Assertions don't have to be observations, and it may also be possible to be both an assertion AND evidence. Thus, they are not necessarily mutually exclusive, but English is too fuzzy to say for sure. 

''Loose use of language is no reason to either perpetuate misinterpretation of assertions as evidence or erroneously conflate them.  If that were acceptable, a statement like "the moon is made of cheese" would constitute evidence that a lunar body is composed of fermented dairy products.  Obviously, it does not.  Logically, a predicate does not constitute evidence of its own truth value.''

There is a big difference between "the moon is made of cheese" and "I tasted the moon, and it tastes like cheese". Strawman strike.

{Right. The former is what you've claimed as evidence. You haven't supplied any of the latter.}

Not that I am aware of. Please elaborate. I observed a relationship between HOF's and "getting stuck".

''With no mention of circumstances -- e.g., language, application, requirements, specific code, programmer experience, etc. -- it's a comment worth exactly what we paid for it.  It doesn't constitute enough evidence to even be worth discussing, let alone declare that in general "HOFs and lambdas confuse programmers."  I've seen programmers confused by 'FOR' loops.  Should we therefore declare that "FOR loops confuse programmers" and stop using them?'' 

Multiple non-newbie programmers were confused by FOR loops? Anyhow, if you don't wish to discuss a given piece of evidence, then simply DON'T. Ignore it and go away. And again, I invite the reader to decide if a given situation matches their shop or not rather than insist they take my word or anybody's word at face value regarding developer behavior. There is no rational reason to keep complaining about that issue. You are being an asshole.

''No, multiple newbie programmers were confused by FOR loops.  I've never known a competent experienced developer to be confused by FOR loops, but I've never known a competent experienced developer to be confused by HOFs, either.''

You are welcome to present that observation. It differs from my observations, but you are still welcome to present it.

PageAnchor for-loop-ugly

I would note that C-style FOR loops ''' ''are'' ugly and unintuitive'''. BASIC has a leg up in that department:

  FOR i = 1 to 400 STEP 2     '// "STEP" is optional, defaults to 1 without
      PRINT "i = "; i
  NEXT i
I'll give the C-style points for parsimony perhaps, but not human intuitiveness.

If C-style is ever overhauled (ItsTimeToDumpCeeSyntax, AlternativesToCeeSyntax), then perhaps something like this can be the replacement:

  for(&i, from=1, to=400, step=2) {...}  // "full" keyword version
  for(&i, 1,400,2) {...}  // positional version 
  for(&i, from=400, to=1, step= -1) {...} // reverse looping example
  // both version could be allowed, similar to how VB.NET and C# do it

[Personally I'd sooner deprecate numerically-indexed for loops entirely, instead providing foreach loops plus standard-library support for producing iterators (internal or external, doesn't matter) over numeric ranges. PythonLanguage took that approach. It's pretty effective. However, that's something of a digression. Programmers have been confused by FOR loops at times. Programmers have been confused by function calls at times. Programmers have been confused by variable assignment at times. Should we really be making blanket declarations -- "this construct confuses programmers" -- based on a few isolated incidents? Should we really be deeming particular constructs too confusing and abandoning them on the grounds of a few isolated incidents? -DavidMcLean]

* As far as FOR loops, like I mentioned elsewhere, a simple base library function used inside a WHILE may also suffice:

  while(for(&i, from=1, to=400, step=2)) {...}  // "full" keyword version
  while(for(&i, 1,400,2)) {...}  // positional version 

* [How would such a library function work? The state of i needs to be carried somehow, and it isn't passed ''into'' for(). How's that state passed? -DavidMcLean]

* You are correct; I adjusted it.

* [Aha. Yep, that version will work, although it does demand the language provide at least explicit support for pass-by-reference, a feature I'd typically prefer to avoid in favour of purely providing pass-by-value-where-the-value-might-be-a-reference as most OO languages currently do. Still, no show-stoppers; that's a perfectly fine design. -DavidMcLean]

* Note that in some languages, you declare pass-by-reference on the definition side such that we may not need to see "&". Also, if the language makes "while" implicit, we'd have shorter ways to "custom" or library-based loop functions. (EditHint: consider forking to another topic.)

      x > y {...}  // a language where "while" key-word not needed: [Boolean expression] {...}
      while(x > y) {...}  // filler "while" function for backward compatibility
      for(i, 1, 400) {...}  // A compact for-loop construct using the "for" function.
      for(i, from=1, to=400) {...}  // key-word parameter version (some langs allow both variations)
      miffle(a, b) {...} // We can make custom loop functions.
      while (miffle(a,b)) {...} // traditional version of the above line

I don't think they are isolated. True, my experience is not a statistically solid sample size, but enough to strongly suggest a pattern in my opinion.

[Can you relate any of your experience on the matter to us? -DavidMcLean]

Not specifics, no; just hazy memories based on multiple encounters, including on-line commentaries, reinforcing a kind of prototypical memory. A typical "composite" encounter resembles, "What's this ugly construct with the curly brackets inside of parentheses? It must be one of those unnamed bohemian function thingies. Why don't they use OOP instead (for API's)? I don't get it." And some of it is just being stumped, as in not being able to fix a bug, without words when trying to fix HOF-centric code. The more hoffy the more stuck-ness.

[What bugs? What is "HOF-centric code"? Which APIs? Which languages? Curly braces inside parentheses suggests either C# or JS, both of which also permit curly braces inside parentheses for expressing various other, non-lambda language constructs. -DavidMcLean]

I don't remember the specific code issues. A lot of the times it was on a project or project section I wasn't even part of.

[Then how do you know higher-order functions were a culprit? -DavidMcLean]

I got curious and looked at the code being complained about.

[So what was the code? In what way was it "HOF-centric"? How was it buggy? What language was it in? -DavidMcLean]

I thought I made it clear why I cannot give coding specifics. By HOF-centric I mean that it had multiple HOF's (or lambda's) in it: the more HOF's, the more the stumpage. True, it's difficult to compare that against the non-stumpies since I'd be less likely to hear about those.

* [If you've seen the code in question and could identify that it had multiple calls to higher-order functions, that implies you were at least aware of what language said code was written in; questions like "how was it buggy" may certainly be more difficult to address, especially if the bugs were not actually tracked down and solved. "the more HOF's, the more the stumpage" seems to be a trivially true assertion but not a particularly meaningful point to make - the more ''anything'', the more confusion there can be, after all. A codebase consisting of nothing is trivial to understand. -DavidMcLean]

* It was usually JavaScript, Microsoft's usual offerings, and perhaps a Java lambda or two.

** ''A Java lambda or two?  That must have been relatively recently -- Java 8 (the first version with lambda expressions) was released in March 2014.''

* [Makes sense -- those're conveniently the major languages we've been looking at here anyway. In the absence of greater specifics, it is impossible to ascertain whether a particular sample of code was impenetrably confusing due to the mere use of particular features or for another reason. Bad code can be written in any language, and with any language construct, after all. Without specifics, we don't really have evidence supporting your particular claim, since there's such a broad spectrum of possible sources of confusion and singling out one specific aspect of the code is potentially disregarding the actual causes. -DavidMcLean]

* Counter claims are likewise weak regarding typical staff behavior/ability. Stop making the same complaint over and over again. It really really is fucking annoying. I really believe you had parent(s) that gave into you if you complained loud and long enough, creating a really annoying personality defect in yourself. Let the goddam reader decide which description matches their own environment. LET IT GOOOOOOOO!

* ''We'll stop making the same complaints about your weak evidence when you present stronger evidence.  Until then, you can also avoid our complaints about your weak evidence by not making weakly-evidenced claims.  I mean, really, do you expect us to make wholesale changes to programming languages and development strategy based solely on your claim that developers are confused by HOFs and lambda expressions?  Do you actually expect us to agree with you given such flimsy evidence?  Surely, you must recognise that to convince someone of a point that differs from their expressed approach, you must present '''overwhelmingly powerful''' and '''compelling''' evidence, not mere hearsay.''

* PageAnchor repetitious-badgering-01

* Re: "We'll stop making the same complaints about your weak evidence when you present stronger evidence" -- That's essentially a '''threat of bullying''', and childish. The evidence I gave is within the acceptable scope/level of evidence of this wiki, whether YOU personally want it to be or not. You are pulling an IwantaPony and PersonalChoiceElevatedToMoralImperative and essentially threatening to e-cry like a toddler using '''repetitious badgering''' if you don't get your way. --top

* ''It's hardly "bullying" to point out a repeated or sustained flaw, but let's assume (for the sake of argument) that the claim you made -- that HOFs and lambda expressions confuse programmers -- is, all by itself, a form of "acceptable scope/level of evidence [for] this wiki".  What, then, is the purpose of that evidence?  It's certainly not enough evidence to make changes to programming languages and development strategy.  It's definitely not enough evidence for us to agree with you.  It's not even enough evidence to be worth discussing the issue it hypothesises.  So, what purpose has this "acceptable" evidence?''

* It's not a "flaw" in the world of this wiki. You are making up rules again. See PageAnchor use01 at AreWeaklyBackedOpinionsAcceptable for a prior reply to a similar claim about the value of such.

* ''It's flawed reasoning to claim a hypothesis is evidence.  You appear to use AreWeaklyBackedOpinionsAcceptable to defend weakly backed opinions on the basis that you "like to know what other people's opinions are", despite the fact that a sample size of 1 is statistically meaningless.  Given that your claim here is also statistically meaningless, as I asked above, what purpose is there in presenting it?'' 

* It's not a hypothesis. Or at least being a hypothesis does not exclude also being evidence. We've been over this already. I don't care what you ''personally'' find "worthless". You are not the God of this wiki. [Angry statement redacted.]

** ShouldWikiTolerateAbusivePeople -- Chauncey

** No, prevent people from repeating the same complaint several times in an attempt to intimidate or bully. Note how Mr. Italics stated, "We'll stop making the same complaints about your weak evidence when you present stronger evidence." That kind of crap should NOT be tolerated.

** ''That's reasonable.  You're using unusually flimsy evidence to encourage significant changes to programming languages and programming practice.  If that is intended to affect what we do as programmers, shouldn't we complain if it's based on so little substance?''

** Projection. YOUR evidence is flimsy.

** ''My evidence of what?  I've made two assertions: 1. That HOFs and lambda expressions can simplify code, which I've shown.  2. That your evidence is flimsy, which is self-evident.  Anything else?'' 

** If stuck using specific existing languages or API's, YES, I already conceded that point (1), but that's not the what the debate is about. 

** ''You wrote, "YOUR evidence is flimsy".  Again, evidence of what?  I've only made two assertions and both are evidenced.''

** If your HOF claims are only limited to existing specific languages/API's, then maybe we are done.

** ''I have pointed out that a fundamental difference between HOFs and their closest OO equivalent (FunctorObject''''''s) is that HOFs/lambdas implicitly close over their defining environment whereas the programmer must explicitly specify it in a FunctorObject.  We can imagine a future language where FunctorObject''''''s also implicitly close over their defining environment, but if a FunctorObject is equivalent to a HOF/lambda, then arguably that's what it is.  Thus, my claim holds true in any existing language/API, and appears to hold true in a particular imaginary future language.  As I can't anticipate all future languages, it would be disingenuous of me to make any categorical statement about future languages.''

*** {You don't need to imagine future languages where FunctorObject''''''s also implicitly close over their defining environment. That's exactly what both C# and C++ lambdas are.}

*** ''Yes, of course -- you're right.''

** Re: "whereas the programmer must explicitly specify it in a FunctorObject" -- I'd like a demonstration of where this is a practical problem.

** ''Sure.  See FunctorVsClosure.''

** I don't see practical examples. Those look like lab-toy kinds of examples and I am unable to extrapolate such into something I'm likely to encounter in the field. I agree it may simplify rare cases, but for staffing reasons I'd accept a simpler language or reduced tool set over simplifying blue moons. (You should have anticipated such a response from me by now. We've been down many similar roads.)

** PageAnchor customized-collation-01

** ''It's very practical, and my examples are based on production code. Customised collation shows up repeatedly in custom business application development, so I thought it would be something you'd appreciate.  If you don't encounter it, I guess you're lucky.''

** Most sorting is done by the database, not in RAM. Some RDBMS do offer the ability add custom collation modules. In practice if the RDBMS doesn't give one the collation needed for a particular need, then one generates a parallel "work column" (in the DB or in RAM) that tweaks the character set or characters to fit intended ordering, and then sorts on the work column (using built-in collating). But I have not seen a wide need for such. And "Now let's imagine that the compare() method needs to make reference to the external environment" makes it even rarer. If you can identify at least 3 realistic business UseCase''''''s, you may convince me of non-rareness.

** ''I thought this threadlet was about the fundamental differences between LambdaExpression''''''s and FunctorObject''''''s, not the application of either one to business UseCase''''''s.  You did ask to see where explicitly referencing the defining context is a problem in a FunctorObject, which appears to be a question about programming constructs.  Are you now changing the topic?''

*** It changed to be about "practical examples". Did you miss the change?

*** ''That, I think, is the source of confusion.  FunctorVsClosure '''is''' a practical example.''

** ''Again, you're lucky if you can do all the collation in the database even with "custom collation modules".  I get problems like "make sure all the SKUs starting with letters are sorted alphabetically, the numeric ones have to be sorted numerically (and appear strictly after all the alphabetic ones) including the ones with a dash in column six but they have to appear just before the 'P'-coded SKUs unless there's an 'N' in the second column in which case blah blah blah..."  Or, I have to accept incoming packets of real-time data and send them out in ordered groups faster than any SQL DBMS can keep up.  And so on.  If you have a way to handle these using a SQL DBMS that's simpler, easier to write, and easier to maintain than the approaches shown on FunctorVsClosure, I'd like to see it.''

*** The "work column(s)" approach mentioned would work just fine for SKU's, and has the side benefit of one being able to study the contents of the work column(s) for debugging, testing, etc. That's easier than intercepting and back-tracing RAM. As far as "faster than DB speed", I don't get a lot of those, as mentioned in other topics. And one usually doesn't need mass swappability of the comparing algorithms even if they did. Conditional/CASE statements are plenty fine most of the time to select among a relatively fixed set of comparing algorithms for RAM-centric processing. Thus, your "improvement" would take two conditions to be true at the '''same time''': 1) Too fast for database usage, and 2) mass swappability of comparing algorithm needed. -t

**** ''I'm very familiar with the "work column" approach, if I understand what you mean by "work column".  I'm not clear, however, how using it would be simpler, more maintainable, or easier to develop than the method shown on FunctorVsClosure.  Can you show how?''

**** ''I'm also not clear what you mean by "mass swappability of the comparing algorithms".  There was no mention of such a thing in FunctorVsClosure.  What is commonly needed is to be able to easily compose sort order definitions from a combination of string primitives like "toUpper", "toLower", "substring", "isNumeric", etc.  Is that what you meant by "mass swappability"?''

*** Further, the pattern of variations-on-a-theme would likely be smaller than a function level, and '''interweave'''. For example, whether we ignore punctuation for comparing may end up being independent from case insensitivity. Modelling it as separate functions or function-like blocks would probably limit you in many cases. If it's "boxed" commercial software, then power-users would typically select features via a front-end and select the combos and filters and groupings they want, not unlike existing Email filtering interfaces. They wouldn't be coding HOF's. Thus, your mass comparer swapping is either unrealistic, or only the best solution in a very very narrow set of situations and circumstances.

*** [Why would variations-on-a-theme ever be "smaller than a function level" when a given function can do as little or as much as is necessary? Any aspect of a higher-order function's operation can be "pulled out" as a distinct argument, after all, no matter how tiny it is. In the case of comparison modifiers, like case-insensitivity and ignoring punctuation, there're a few options: You might have a factory that produces appropriate comparison functions, allowing options like case-insensitivity and disregarding punctuation to be toggled on and off using parameters. This is reasonably straightforward to implement but sadly not particularly extensible if new modifiers are necessary. Alternatively, and far more extensibly, you can simply exploit function composition to construct appropriate comparison functions where necessary; this approach is extremely common in HaskellLanguage for example, where you'd write something like "sortBy (comparing $ map toLower)", or "sortBy (comparing stripPunctuation)", or "sortBy (comparing $ map toLower . stripPunctuation)" when you need both. This approach is trivially extensible, and the transformation functions used are also available for other purposes besides comparison-for-sorting. How would these approaches "limit you in many cases", exactly? What cases do you have in mind? As for commercial software configured by power-users, that's certainly a viable product to build, but why wouldn't it involve higher-order functions? Sure, power users don't have to use higher-order functions -- or any code at all -- but there has to be an implementation sitting behind that front-end. Why wouldn't the front-end act as a factory spitting out comparison functions, to be dropped into sort functions, filter functions, and so on elsewhere in the application? -DavidMcLean]

*** You are right that functions can be as small as we want them (excluding function packaging overhead), but that does not necessarily mean it's the most practical or best way. Anyhow, without exploring a specific specification and written pattern, it's difficult to say which is the ideal here. There are many ways to skin a cat with two birds.

*** ''Try illustrating my example from above -- to "make sure all the SKUs starting with letters are sorted alphabetically, the numeric ones have to be sorted numerically (and appear strictly after all the alphabetic ones) including the ones with a dash in column six but they have to appear just before the 'P'-coded SKUs (i.e., those that start with a 'P')" -- using SQL.  Following the approach of Example 3 on FunctorVsClosure, I've written a Java 8 example at CustomCollationOrder that solves the problem.  When yours is done, we can compare.''

*** I'll address that example at CustomCollationOrder.

** ''As for your "3 realistic business UseCase''''''s", I really shouldn't rise to such questionable challenges as it's not my place to convince you whether you need certain programming constructs or not.  That's your problem, not mine.  However...  Aside from the custom collating shown on FunctorVsClosure, here are two other examples where I've used FunctorObject''''''s that needed to reference their defining environment:  1. Defining the fitness function for a system used to do employee scheduling using GeneticAlgorithm''''''s.  2. Defining the heuristic function for a system used to do logistics routing using A*.  Obviously, if the kind of custom business applications you do aren't the kind of custom business applications that I do, then maybe FunctorVsClosure isn't applicable to you.  I've also done a fair number of applications that consisted entirely of forms to take in data, databases to store it, and reports to present it -- all in a strictly linear and non-concurrent fashion.  Outside of the usual GUI event handlers, I can't think of any reason to use HigherOrderFunction''''''s, LambdaExpression''''''s, or FunctorObject''''''s in such applications.''

* [Being a hypothesis and being evidence to support a hypothesis are mutually exclusive. What your correspondent "personally find[s] 'worthless'" isn't relevant. No one mentioned anything being found "worthless", or even used the word, until you did just then. -DavidMcLean]

* An observation that X tends to result in Y is considered a form of "evidence" by most people. Whether it's ALSO a hypothesis, I'm not going to entertain because it's moot. I pointed this out already and you ignored it. '''It only has to qualify as "evidence" to pass the wiki test'''. Whether it's also a hypothesis or a zit or an airplane doesn't matter. It passed the necessary test already. QED.

* [But it doesn't qualify as evidence. "X tends to result in Y", sans backup, isn't evidence; it's a baseless assertion. The "necessary test" isn't being passed. -DavidMcLean]

* You are making up extra rules. Accept your wrongativity and go home. And '''you misquoted me'''. I said an OBSERVATION that... If I had ONLY said "X tends to result in Y", your statement would be correct. But that's not what I said, and therefore your statement is incorrect as a feature of my statement.

* [How so? -DavidMcLean]

* You invent rules out of the blue with your mind when your logic is otherwise flawed. And you misquoted me because you are manipulative.

* [How so? And if I invented them out of the blue, why do they correlate with the rules presented by your other correspondents? (And no, I did not misquote you. I omitted the word "observation", because the fact that "X tends to result in Y" is an observation does not change anything; I don't intend to imply that it ''isn't'' an observation, just that it doesn't matter that it is one.) -DavidMcLean]

* What "rules presented by your other correspondents?". Anyhow, I don't want to do the LaynesLaw dance with "evidence" anymore. LetTheReaderDecide if it's evidence or not.

* ''You're trying to sustain lengthy arguments, and encourage change to languages and programming practice on the flimsiest of evidence (or not).  Do you think that's reasonable?''

* YOU make them lengthy by complaining about inconsequential things. And I am not changing practices, many developers already do ignore FP if not forced on them by the language or API's available. Software engineering is already a flimsy discipline anyhow because too little solid research is done and available. Before Mars was explored by probes, many books were written about it based on telescope and spectrograph observations, which didn't supply very much. That's how fields typically work: many speculative alternatives are explored based on the limited early evidence. As more evidence comes in, less speculation is needed. 

* ''Encouraging change to languages and programming practice without evidence is hardly "inconsequential", regardless of the state of SoftwareEngineering in general.  You're certainly correct that "speculative alternatives" are explored as evidence grows, but that's not the case here.  Do you really think you have enough evidence to suggest changes to programming languages and programming practice?  We don't.''  

** Because there is no solid evidence of developer behavior '''either way''', we can present BOTH and let the reader select which best fits their own shop:

        // algorithm 376
        if reader-shop-developer-behavior-fits-pattern X then
          here-is-sample-code-catering-to-X
        else if reader-shop-developer-behavior-fits-pattern Y then
          here-is-sample-code-catering-to-Y
        else if reader-shop-developer-behavior-fits-pattern Z then
          here-is-sample-code-catering-to-Z
        etc...
.

** It's fair solution to the poor-evidence conundrum.

** ''That's reasonable.  Feel free to show such sample code.  Alternatives to HOFs and lambda expressions, especially for languages that don't have them, could be useful.''

** For scenarios that fit the kind of projects I see, I have been doing such.

** ''You've done so with GUIs, and that's fine.''

** And "timer" API's.

* ''Sure, many developers ignore many things.  So?''

What surprised me is that heavy factoring into "too many functions" (regular functions) also stumped or slowed down programmers with a good standing. At first I thought it was just outliers having the problem and kept up the factoring in subsequent orgs. But the same complaint kept rolling in.

[Programmers that can't handle "too many functions" are not in fact skilled programmers. Lots of little, composable functions (and classes and objects and modules) is fundamentally the essence of good program design. -DavidMcLean]

As explained in IndividualExperienceShapesPerceptions, they are often not the best "code jugglers" around, often because they are selected by many criteria, raw coding being one of multiple. Good coders do exist in such environments, but you are expected to cater toward the average, not the current or best staff encountered. (Often the best coders have the poorest people skills.) One guy was a pretty good coder, but unfortunately he didn't comment anything because he believed in self-documenting naming. He took self-documenting as far as it could go, though. Most coders are a trade-off of traits, including quirks. If they were masters at everything, they'd probably be making buko bucks somewhere else rather than be an average-paid coder in an average company. I am surrounded by Salieri's, not Mozart's.

''It sounds like you work in an environment that is at least somewhat influenced by what is often called end-user computing -- technical work, especially programming, done by relatively non-technical people who would not consider themselves to be professional programmers.  Don't such developers normally use domain-specific languages, such as Qlikview, Cyberquery, Excel macros, VBA, and so on?  Perhaps rather than limiting general-purpose language features to suit such developers -- which would limit what professional programmers can do -- there should be more development and promotion of domain-specific languages that target a relatively "I'm not really a programmer" audience.''

''I'm not saying particular language features such as HOFs are necessarily more confusing than any other feature, but I do suspect the overall complexity of general-purpose programming languages may represent an aggregate difficulty level that professionals -- who are not professional programmers per se -- can find overwhelming.  Better languages specifically targeted to that audience may be a solution.''

You seem to imply a definitive dichotomy between "professional" and non-professional, which is not what I find. It's difficult to explain how and what they do without witnessing it for years. They are perfectly capable of producing custom applications to solve specific organization needs. But if you look at their ability to work with code in terms of code alone, they are far from the cream of the crop, on average. As long as one does not use certain structures, techniques, and patterns that confuse them, they can absorb it well enough to do the job at hand. They can drive cars, but not race in NASCAR. Some are otherwise quite productive if they are in their comfort zone. Sure, it takes more typing if you don't factor well, but they can indeed type fast and copy and paste fast and re-copy-and-paste fast to undo their last copy-and-paste job to make changes. '''If you practice copy-and-paste coding long enough, you do get pretty proficient at it''' such that you can approach the productivity of factoring and high abstraction.

''Your response confirms my view.  "They can drive cars, but not race in NASCAR" is a good analogy.  General-purpose programming languages, like Python/Ruby/Javascript/C/C++/C#/Java/Perl/etc. are equivalent to NASCAR race cars -- tools for professional drivers/programmers.  Qlikview, Cyberquery, Excel macros and VBA are like passenger cars -- tools for professionals, but not professional drivers/programmers.  Perhaps we are in ViolentAgreement.''

Those tools you mention are generally not powerful enough such that C#, Java, etc. are used instead. It's true the programmers usually don't leverage the full power of such languages. If you start out in a wimpy half-ass-programming tool, then it '''doesn't scale''' if you later need to expand it and you have to start over. If you use say C# or Java, then you have the '''option of hiring skilled consultants or cream-of-crop experts''' if and when you need to ramp up features. The ability to ramp up features/complexity if and when needed is highly valued in the biz world. This DOES mean that typical programmers are using tools with features beyond their abilities, but that's the price a typical org wants to pay to gain future potential scaling.

''Then the price (for lack of a better term) that your typical programmers will have to pay for using C#, Java, etc., is having to deal with advanced features and overall complexity.  Perhaps effort should be devoted to developing languages -- perhaps even as a subset of full Java/C# functionality -- targeted at non-professional developers.  Perhaps that's something you could develop.''

I generally agree that such a language(s) should be explored, but it's usually not a problem having the features as long as somebody doesn't over-use them. Plus, having an "X lite" may create a stigma that developers want to avoid and could make hiring more difficult. We are dealing with human beings and their egos here, not robots. One learns to pay more attention to such factors in cubicle-land over time in order to understand the preferences of managers and HR.

''How do you distinguish using a feature from over-using a feature?''

Perhaps something somewhat along the lines of a DualTypingLanguage where certain language constructs can also be required and/or "locked off". Thus, if a shop didn't want anybody to use HOF's, they could lock that feature in the master config file(s).  
But using technology to spank people rather than human policing doesn't have a very good track record in smaller shops.

''Why lock features?  Why not make it a house policy not to use certain features?  Some shops, for example, forbid multiple inheritance in CeePlusPlus.''

''I like your DualTypingLanguage.  You should implement it.''

''It should support HigherOrderFunctions, LambdaExpression''''''s, PrototypeBasedProgramming, first-class tuples and relations as per the RelationalModel, and MultipleDispatch too.''

''I think it might be DylanLanguage.''

-----

The evidence is not ''just'' my anecdotes. I've quoted a Ruby on Rails critique that made similar observations about staff and "ideal" languages/techniques.

And there are other subject areas with a similar pattern: GuiStaffingAnalogy.  And the actual market itself: IfFooIsSoGreatHowComeYouAreNotRich. It's allegedly so great but NOBODY has yet leveraged the GoldenHammer on a large and repeatable scale.

Yes, I know, you probably disagree with the power or scope applicability of the above evidence pieces, but they are still evidence pieces. -t

''What do any of those anecdotes have to do with HigherOrderFunction''''''s or LambdaExpression''''''s?  I've made no claims about FunctionalProgramming in general (other than that its presence is growing), or about RubyOnRails, or about any supposed GoldenHammer.  I only claim that HigherOrderFunction''''''s and LambdaExpression''''''s are superior language constructs -- compared to their alternatives -- for solving certain problems.''

It's about "evidence" in general, at least in terms of the value of anecdotal evidence. This topic is a mix of technical detail and evidence-related issues.

''That may be where you'd like to steer it now, but look where it started (see the very top of the page) and what the vast majority of the content is about.  For "evidence" in general, see "science".''

The general premise that certain coding structures, techniques, or styles can confuse typical developers is at issue. As far as "science", you don't use any; you just think you do because you are narrow-minded and view things through a narrow-minded viewpoint and optimize things based on that narrow viewpoint.

''When you have more than opinions -- mainly your own -- to back up your assertion that "certain coding structures, techniques, or styles can confuse typical developers", then we'll discuss it.  Maybe.  I'm no more interested in holding back language evolution to suit mediocre developers than engineers are interested in limiting distribution of hand tools lest mediocre mechanics get confused about which end of a screwdriver is the grip.''

''As for science, it depends on evidence.  I've provided evidence for my hypothesis regarding HigherOrderFunction''''''s and LambdaExpression''''''s at FunctorVsClosure and CustomCollationOrder.  What evidence have you provided for your hypothesis?''

That's because you are naive and inexperienced about business and economics, thinking symbolic optimization is the one and only and default thing to optimize around, but which is otherwise an arbitrary factor to make The King. Where is your evidence that parsimony "should" be the only factor to consider? Where is your scientific proof? 

''Where do I make the claim that "parsimony 'should' be the only factor to consider"?''

''Actually, having spent many successful years in commercial and bespoke software development, I think I have a pretty good idea of the business and economics of the software field.  As a result, I don't doubt that non-professional programmers (who may be professional data analysts or accountants or any of a thousand different professions) -- the sort who create reports in Cognos BI and simple scripts in VBA -- might have difficulty with HigherOrderFunction''''''s and LambdaExpression''''''s.  Fortunately, they don't need HigherOrderFunction''''''s and LambdaExpression''''''s (because nobody "needs" them, any more than anyone "needs" FOR loops when there are WHILE loops) and the languages they usually use don't have them.  Professional developers, who use C++/C#/Java/Javascript/Haskell/Python/Ruby/Scheme/you-name-it, do benefit from HigherOrderFunction''''''s and LambdaExpression''''''s and that's why the languages they use have them.  The occasional developers who find them confusing -- perhaps because they're language features they haven't used or seen before -- learns them.  That's what professional programmers do.  Non-professional programmers who use C++/C#/Java/Javascript/Haskell/Python/Ruby/Scheme/you-name-it are used to the fact that the languages they use have features they don't use.''

** Also, some of the langs may be using H & L's to plug weak points in their poor OOP implementations.

** ''What weak points are those?  Be specific.''

** Excessive differences between class and object. Others are also helpful such as ability to add or change methods after declarations, and ability for parent methods to optionally execute in addition to child method.

** ''I can appreciate that you favour prototype-based OO over class-based OO, but I don't know that distinguishing class instances from static classes is an "excessive difference".  How is it an "excessive" difference?''

** ''Dynamically adding methods to instances is a nice feature, but I'm not clear how it's helpful in comparison to HigherOrderFunction''''''s/LambdaExpression''''''s to have it, or how that relates to the "ability for parent methods to optionally execute in addition to child method".  Could you expand on this, perhaps with examples of code?''

** We touched on some of these in the NodeJsAndHofGuiDiscussion topics.

** ''Touched, yes.  None of your examples are described sufficiently to determine whether they're better OO or simply unfinished, and there's some opposition to your assertion that your approach is superior.  For example, InAppQueryExample is clearly incomplete.''

** I never claimed it "superior"; only reasonably competitive in terms of code size (within say 10%). The selling point is that it leverages ''existing'' developer knowledge and familiarity with OOP rather than require introduction or integration of a new paradigm/idiom. Grokking often overrides parsimony, in my economic opinion. As far as InAppQueryExample, I don't know what its actual production use and change pattern would likely be such that I cannot recommend an OOP API design tuned for the (unknown) need. It's essentially a lab-toy example at this point. If we assume rather open-ended needs, then I call GreencoddsTenthRuleOfProgramming.

*** ''But DavidMcLean, below, is right -- your approach requires new features that are -- by definition of "new features" -- neither as familiar as conventional OO, nor are they as familiar as the HigherOrderFunction''''''s and LambdaExpression''''''s now found in all the most popular, mainstream programming languages.  As for InAppQueryExample, you appear to have started it and stopped part way.  If you thought "its actual production use and change pattern" wasn't sufficiently known to "recommend an OOP API design", why start it?  Furthermore, are you showing an OOP API design, or are you showing how conventional OO can be changed in order to avoid needing (or wanting) HigherOrderFunction''''''s and LambdaExpression''''''s?  I thought it was the latter.  Even if it's the former, if you're going to successfully leverage "existing developer knowledge", doesn't it make sense to implement approaches that are general-purpose and independent of "actual production use and change pattern" -- so that they remain consistent, and thus genuinely leverage "existing developer knowledge" -- rather than varying with each "actual production use and change pattern"?''

*** The "existing language" issue is addressed below. As far as the second half, it appears there is a mix-up between API design and language design. API design is typically heavily influenced by intended use. A super-duper flexible "query interface" will essentially resemble or reinvent a database.

*** ''What is the mix-up?  Did you intend to illustrate API design or language design?  The point isn't the "query interface"; it's merely a familiar illustration.  It could as easily have had nothing to do with querying data structures.''

*** Familiar illustration of what practical or common issue? There's plenty of lab-toy-like illustrations out there showing all kinds of meta-programming and abstraction tricks. The problem is applying and/or evaluating them from the standpoint of typical ("real") applications and application developers. We don't need more lab-toy examples, that's not the bottleneck. In practice code won't juggle that many aspects at the same time because either the domain '''constrains some''' or the application is partitioned in a way as to not overwhelm developers. '''Excessive indirection confuses''' typical developers, for good or bad. Some dimensions will be nailed to the floor (hard-coded or copy-and-pasted) to avoid too many "free variables" at the same time. For example, the division between application and database sometimes creates artificial boundaries, but those boundaries also allow DivideAndConquer among staff so that database experts can focus on the database-ish things and app developers can focus more on behavioral or UI aspects. A perfect brain probably wouldn't need such partitioning.

** [Doesn't your approach still require the introduction of new language features, though? Existing OO languages don't have a keyword to make parent methods optionally execute in addition to child methods, for example. Why is learning ''these'' new, unfamiliar features preferred over learning first-class-function-ish features? -DavidMcLean]

** I don't believe the "child method" issue was a significant one. We were already comparing apple designs to orange designs at that point such that a direct parsimony score-card is not possible. It was mostly meant as an illustration that OOP could be made more flexible in general. And I have already surrendered on the "existing language" issue multiple times and am wondering if our revisit here is due to forgetfulness. But remember that the limits of existing languages could be very well the reasons we find FP constructs in them. It appears to be '''a fad to plug OOP gaps with lambda's and HOF's'''. Focusing on OOP makes a language management party look like legacy fogies. OOP is no longer hip like it was a decade ago. Language designers are for the most part fad chasers just like humans in general.

** ''Languages designers are fad chasers?  That's a peculiarly negative assumption.  Language designers I know (and almost every ComputerScientist or SoftwareEngineer gives it a go at least once) are generally scratching an itch in terms of achieving greater flexibility, composability, expressiveness, clarity or notational power.  I've never known a language designer to implement a feature because of a fad, nor do I know any language designer who would consider FunctionalProgramming to be a fad.  I know programmers and language designers who are not interested in FunctionalProgramming, but you're the only developer I've ever heard of who thought FunctionalProgramming was a fad.''

** As hinted at in ProofObligation, a "computer scientist" will often focus on "symbol optimization" instead of WetWare (inter-human communication) optimization, and thus their tools are often eventually ignored by the market or niche-ify. And most typical developers go with the flow, following the money. If FP pays more, they learn FP. If Goat-Oriented-Programming pays more, they go with tha-a-a-a-a-t too. They'll even appear to embrace things themselves to look "with it". Few will stop to ask, "How could Java OOP potentially be improved to allow less-bloated event block additions without using FP constructs?" Most are non-curious and non-critical at that level, beyond grumbling such as "What's this goofy shit?"


* That sounds like ridicule that comes across like, "The good guys use HOFs but the evil lazy dummy-heads don't". You are essentially defining "professional" in your own way. Anyhow, we've had this argument many times before. I don't know what the hell you have been observing, but it doesn't match my observations at all. It sounds like another planet. LetTheReaderDecide which profile fits their own org to apply algorithm 376.

* ''What a curious interpretation.  Where have I come even remotely close to implying that "[t]he good guys use HOFs but the evil lazy dummy-heads don't"?''

* Your (fictitious) dichotomy between "professional" and non-professional. That's a vast over-simplification. There are a variety of skills, both code and non-code that they are typically evaluated on, and high-abstraction or all-paradigm coding is one of many. [Changed recently, after reply below written.]

* ''I didn't claim anyone was "professional" vs "non-professional".  It's possible to be a professional accountant or professional business analyst, say, and not consider yourself (or be considered by others) a professional programmer even if you write code all day.  Of course "professional programmer" vs "non-professional programmer" is a simplification, but so is almost any other single adjective used to identify a large collective.  Would "trained programmer" vs "untrained programmer" serve any better?  It's certainly no worse than your use of "typical programmer", and much less deprecatory or discriminatory than the abilities you claim the "typical programmer" doesn't have.  Furthermore, there is nothing particularly "high-abstraction coding" about HigherOrderFunction''''''s and LambdaExpression''''''s.  In terms of abstraction level, a HigherOrderFunction or LambdaExpression is a function, differing only from non-HOF/non-lambda functions in that the former can receive or return a function and the latter doesn't have a name.  These are minor differences in characteristics, not greater abstraction.''

It doesn't matter anyhow, the reader can apply algorithm 376 to find the best match for THEIR situation such that asking for confusion proof is mostly moot. You are just being an obsessive dickhead due to a personality defect. This obsessiveness causes you to argue about the same thing over and over again redundantly and repeatedly redundantly because your obsessive personality defect causes you to to argue about the same thing over and over again redundantly and repeatedly redundantly.

''That's a mature response.''

GIGO

''GarbageInGarbageOut?  In this context, that doesn't even make sense.''

{Pearls before swine. Makes sense to me.}

----------
CategoryEvidence, CategoryBusinessDomain