In App Query Example

[under constru

Some languages, such as Coldfusion and MS VB.Net and C#, allow one to use SQL or SQL-like clauses on certain collection types, but below assumes that feature is not available and uses OOP instead.

 // Alternative usage 1
 class allDraftees extends query{
    filter(p) {
        return p.age() >= 18 && p.age() <= 25 && p.gender() == Gender.MALE;
    }
 }
 class allPilots extends query{
    filter(p) {
        return p.age() >= 23 && p.age() <= 65; 
    }
 }
 robo.emailContacts(pl, allDraftees);
 robo.phoneContacts(pl, allPilots);
 //
 // Alternative usage 2
 class allDraftees extends query{
    start {   // optional constructor
       robo.emailContacts(pl, self);
    }
    filter(p) {
        return p.age() >= 18 && p.age() <= 25 && p.gender() == Gender.MALE;
    }
 }
 // Class can optionally run its own processes
 //
 // Alternative usage 3 - pre-select contact method and run
 class allDraftees extends query{
    useEmail = True;
    usePhone = True;
    runImmediately = True;
    filter(p) {
        return p.age() >= 18 && p.age() <= 25 && p.gender() == Gender.MALE;
    }
 }
 // Unset process selectors (flags), such as mail (snail-mail), default to False

Aside from not being Java, all of the above seem little different from RoboCallTest03.java at http://blueskyworkshop.com/topics/Java-Pages/lambda-predicate/

Java is a poor language. And it's closer to RoboCallTest04, not 03.

Java is an actual runnable language, and the Java examples are runnable in it, unlike the above. It's definitely closer to RoboCallTest03.java, because RoboCallTest04.java uses LambdaExpressions whilst RoboCallTest03.java uses method overriding, just like your code above.

Well, it's not a runnable language. If that bothers you, then seek therapy. And whether it's closer to #3 or #4 is an unimportant issue such that I will not debate the classification/match-ativity any further.

It's a somewhat important issue, because one of the points made by http://blueskyworkshop.com/topics/Java-Pages/lambda-predicate/ is that RoboCallTest04.java is simpler and clearer than RoboCallTest03.java because RoboCallTest04.java uses LambdaExpressions instead of method overriding.

The vast majority of the time a database is used for this kind of thing anyhow so that from my perspective it's merely a LabToyExample? and does not "solve" a common need as I encounter in the field. The rare cases we need in-RAM filtering, there are not enough variations such that using CASE/IF statements inside the row loop is good enough due to the low quantity of variation due to the rareness. If there WERE a lot of variations or combo's, then we'd buy/use a database and/or a language that has built-in SQL.

What you personally "encounter 'in the biz'" or "in the field" is irrelevant, especially if you're unable to recognise either that other people "in the biz" may have different requirements, or that the example at http://blueskyworkshop.com/topics/Java-Pages/lambda-predicate/ is illustrative rather than production code. If the example isn't relevant to you, at least try to imagine that it may be relevant to others. Note that there are innumerable problems for which SQL is wholly inappropriate. Would you use it to construct a 3D graphics rendering engine or a word processor? No.

Okay, but you seem to flip-flop between promoting FP for everything and admitting its benefits may be largely niche-dependent.

I've never promoted "FP for everything". I've only identified certain language features (which do come from FunctionalProgramming) as being superior to their alternatives. As I wrote on CustomCollationOrder: "There's no argument here, by the way, that HOFs/lambdas are the 'best' way to achieve anything" ... let alone that they should used for everything... "except for requirements where the alternatives aren't as good. For example, if you wish to define dynamic specialisation of a generic algorithm, and IF/CASE statements would involve editing existing code, and accessing a SQL DBMS would involve unacceptable overhead or the problem doesn't involve querying, and a FunctorObject requires reference to its defining context, and method overriding doesn't allow the desired degree of dynamism, then use of a HOF/lambda is probably the best choice."

That doesn't make HOFs/lambdas niche-dependent, it makes them requirements-dependent. If you never require HigherOrderFunctions or LambdaExpressions, that's fine, but recognise that other developers may benefit from them.

I don't disagree that there are times and places where they may make a noticeable improvement in code size and perhaps maintenance effort (volume of code that needs changing). But we do seem to disagree about the frequency of such occurrences and perhaps the range of domains, and whether such cases are common enough to justify recommending them for general shop use. I guess we both agree ItDepends, but not on how much and how often ItDepends. Obviously if you cannot use an RDBMS or RDBMS-like tool(s) in your domain/project but need query-like features, then the tradeoff profile and design option set is much different than if you could use them.

If there is a particular "range of domains", frequency of occurrences, or absence/presence of pre-existing tools/libraries/subsystems, it's irrelevant. Assertions about what (maybe) usually happens in the field, like "in general, <x> tool is available" or "in general, programmers are <x>" or "in general, our domain does/doesn't <x>" are irrelevant unless they can be supported with strong and compelling evidence. The only thing that matters is whether or not a given programming requirement -- obviously under the constraints of a given project, in practice -- can be better implemented with certain language features.

I have to disagree. For one, if I have no solid evidence that X happens often beyond personal observation, that doesn't mean that X is rare. The frequency of X in either direction has week formal information behind such that anecdotal or personal observations play a role. If you can't get Mercedes evidence, you'll have to do with Chevy evidence because Mercedes evidence simply isn't available. You may want this wiki to be formal-or-nothing evidence-wise, but you are not the final arbiter. I am damned tired of you making that same complaint over and over repeatedly redundantly over and over. I disagree with it still and repetition will NOT change my mind. (See EvidenceDiscussion.)

If we don't agree that X is common, why do you expect us to discuss the implications of X as if X is common?

And introducing a paradigm/technique into the software may confuse maintenance staff. In my observation, the cost of confusion is often far greater than the extra carrying costs of somewhat extra code volume unless that technique is used often, in which case the training or confusion bump is spread out over a larger volume of code. Your symbol-centric viewpoint is economically flawed by my observations. Software is mostly about WetWare, not symbol optimization, when one spends the time and effort to observe economic issues rather than just symbol issues (parsimony, etc.). -t

You seem to be assuming that I agree that X is common, where X = "introducing a paradigm/technique into the software may confuse maintenance staff". I don't agree. I don't think it's common. I think, in fact, it's very rare among professional developers. It might be common amongst end-users who do some development, or even those shops where developers are drawn from non-programming backgrounds, but they're a speciality category in which I have no interest. My interest is in extending the capabilities of programming languages to empower professional programmers. If your interest is discussing how to limit the capability of programming languages in order to suit end-users who do some development, then it's diametrically opposite to my interest and I oppose it categorically. I have no interest in discussing how we can go back to writing programs like we did using ExBase circa 1987, because I was there, I did it, it sucked, and I'm not doing it again. Likewise, I have no interesting in arbitrarily stopping language evolution at C# 2.0 and Java 7.

I know you disagree about what confuses typical developers. That's not new information on this wiki. And just because YOU are bad at grokking ExBase doesn't mean everyone is. (I suspect you were trying to use it outside of its intended niche. Note in my observation, a typical ExBase developer was more productive than a typical C# programmer, except in cases where fine-tuned control over the PC and graphics was highly prized by the customer. Whether a high-end ExBase developer was more productive than a high-end C# developer, that's hard to say, but mostly moot.) But let's try not to wonder off topic into the general "confuse" debate yet again. LetTheReaderDecide which developer profile bests matches their own shop, and apply the rest accordingly. Trying to establish a universal default developer grokking profile for this wiki has proven fruitless and pointless.

If that's your view, why do you repeatedly inject your beliefs about it into these discussions in the form of "... may confuse maintenance staff" or "... confuses typical developers"?

Simple: You state your summary of benefits, and I put my summary counter-benefits. If your summary benefits are usually the same, then likewise my summary counterpoints are usually the same.