A discussion branch off of SummaryOfHofExamples

[Perhaps, ''if'' parallelism is all we need in the application. What happens when we find we can use an InternalIterator too? Maybe an EmbeddedDomainSpecificLanguage or two? Event handlers? An algorithm we need to inject customisation into? What happens when we need all of those things, yet we only know about a "parallel" block construct? -DavidMcLean]

What if Lisp-speaking aliens land all around us? I'd have to study specific scenarios on a case-by-case basis and weigh it against the alternatives. If I actually see '''common''' uses for such in my niche, I'll consider it. So far, not. (The issue of requirements frequency keeps popping up in these debates.) For example, a task- or department-specific API is often used rather than an EmbeddedDomainSpecificLanguage. A full EmbeddedDomainSpecificLanguage is generally only justified if it's to be heavily used, in which case a expert on EmbeddedDomainSpecificLanguage is usually brought in.

[I'm not sure you're clear on what an EmbeddedDomainSpecificLanguage ''is'', if you're drawing a distinction between one and a "task- or department-specific API". The average EmbeddedDomainSpecificLanguage is ''exactly'' a task-specific API; it's just one that happens to gear the language's existing syntax to the domain. Take a look at RSpec, Rake, or Sinatra for illustrative and popular RubyLanguage examples - or their JS equivalents, if you prefer (Mocha, Jake, and Express, respectively). You don't need a special EmbeddedDomainSpecificLanguage expert any more than you need to bring in an expert for every other library and package your solution requires. As for the rest of your response, as I implied above your argument relies on the assumption that we only need parallelism, and even more specifically that we only need ''one specific kind'' of parallelism. It's exceedingly easy to run up against the limits of such a restricted construct; trivially, suppose we suddenly needed the ability to query in serial, such as to access a ControlTable and dispatch on the result. In addition, again, you're spending complexity on one very specific use instead of a general tool that solves a wide range of problems - even if we only need that one kind of parallelism, what if we have events? Do we introduce a whole separate language construct for binding event handlers? Why encourage LanguageIdiomClutter when we could just as easily use the same construct for both needs? -DavidMcLean]

That's essentially SystemsSoftware, which I've already agreed can probably make better use of HOF's. And sometimes LanguageIdiomClutter seems to work better in the field; I don't know why, it's just the way typical humans are. See GreatLispWar.

['''What's''' essentially SystemsSoftware? I mentioned a bunch of things. Resolve your pronouns. -DavidMcLean]

Writing new languages or API's intended for a wide audience or audience outside one organization is generally SystemsSoftware: tools used BY application developers. It's generally not worth it to make a custom language for a small audience; API's and "helper functions" are sufficient and don't require hiring language specialists. And if you wish to flesh out more examples, please do, but remember this is a summary page.

[Seems perfectly reasonable, but I don't mean to claim you'd necessarily want to ''write'' an EmbeddedDomainSpecificLanguage, nor any complete libraries, specifically for your application. All that I suggest, and all that the examples I provided demonstrate, is that you might want to ''use'' an EmbeddedDomainSpecificLanguage as part of your application. Sinatra and Express are helpful for writing Web apps. RSpec and Mocha help you write unit tests. Rake and Jake help you write build tasks. All those things can be of use in an application. (Of course, if your application surpasses a certain level of complexity, it ''might'' become valuable to start building elaborate libraries and even the occasional EmbeddedDomainSpecificLanguage to keep the code flexible and generally compact. But it also might not; it's far more likely that you'd need to ''use'' these things than ''build'' them.) -DavidMcLean]

BusinessRulesMetabase describes alternatives to a custom language. It caters to power-users who are not expected to be programmers, but can handle quasi-programming of business. Sometimes orgs have power-users who can program, but I've seen cases where when they move on or retire, their replacement cannot figure out their stuff. A BusinessRulesMetabase, on the other hand, is a '''more transferable interface'''. Again, one typically has to target a typical staff member for a given position, not an advanced one.

[A BusinessRulesMetabase seems to be operating in a completely different field to the tools presented. Why would you want "power-users" defining your Web app's routing and request handling, or your unit tests, or build steps? Those things (with the maaaaaybe-an-exception of routing) all have no visible impact on users. -DavidMcLean]

I thought we are talking about domain tools, not programmer tools. What do you mean by "routing and request handling" for web apps?

[We're talking about EmbeddedDomainSpecificLanguage''''''s, but the examples I chose are for domains that do not typically concern end-users. Take a look at Sinatra or Express. They provide an EmbeddedDomainSpecificLanguage for describing Web app routing, e.g., the code that dispatches a GET request for /some/particular/url/with/parameters/like/5 to the appropriate code for handling that request. -DavidMcLean]

It sounds like a hybrid WCMS and programming framework. I probably couldn't evaluate such a product here and now effectively. I don't dispute that it "works", but the issue is how it compares to alternatives. Is there a particular feature of it you wish to illustrate? And are you saying HOF's make it easier on the DSL creators or users or both? -t

[Nah, Express and Sinatra aren't CMSes, just Web frameworks; they're only meant to serve as examples of EmbeddedDomainSpecificLanguage, so nothing specific to these frameworks alone is particularly relevant. And my claim is that the use of a DSL, built with anonymous and higher-order functions, makes the API friendlier and more flexible for its users. -DavidMcLean]