Evidence Discussion
Evidence DiscussionMoved 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.
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.)
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.
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?]
while(for(&i, from=1, to=400, step=2)) {...} // "full" keyword version
while(for(&i, 1,400,2)) {...} // positional version
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.
// 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...
.
[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, LambdaExpressions, 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 HigherOrderFunctions or LambdaExpressions? 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 HigherOrderFunctions and LambdaExpressions 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 HigherOrderFunctions and LambdaExpressions 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 HigherOrderFunctions and LambdaExpressions. Fortunately, they don't need HigherOrderFunctions and LambdaExpressions (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 HigherOrderFunctions and LambdaExpressions 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.
That's a mature response.
GIGO
GarbageInGarbageOut? In this context, that doesn't even make sense.
{Pearls before swine. Makes sense to me.}
EditText of this page
(last edited October 17, 2014)
or FindPage with title or text search