Remember, according to the constructor theory, the most fundamental components of reality are entities - constructors - that perform particular tasks, accompanied by a set of conventions that define which tasks are possible for the constructor to carry out. Tasks are descriptions of transformations or changes. Constructor theory can help to generalize theories like that of computation, unifying formal statements, expressing the principles of testability and computability...
Tasks created by functions
I look into it through the lens of a practical problem solver (with a mathematical background) seeking computability. A task in computing is a description of transformations of objects...or even a (one task) workflow. In programming we talk about task oriented languages if their statements express what to do and not how and we usual expect them to be domain-specific (offline robot programming - a prototype). Symbolic programming is a programming paradigm that supports task orientation perfectly.
My reference of a language that empowers task oriented (symbolic) programming is the Wolfram Language . We extended it into the universe of quant finance and made it domain specific - UnRisk Financial Language. See an example here.
In batch processing tasks are scheduled, but they can be also performed by interaction.
Event based modeling (and analysis)
In how innovations change our lives I've emphasized the structure type. In quant innovation we often deal with flow-oriented (complex) systems that are event driven - objects are transformed and interact triggered by external and internal events. It may be a financial instrument in a portfolio that is called (by the issuer), a few parts that need to be assembled to a function complex, a robot that need to avoid a collision…tasks in such frameworks have a time dimension.
They need informative data (preprocessed), information about events, models, algorithms, event detection algorithms, knowledge representations…actions (to be taken immediately after an event occurred).
The focus is on real-time decision support. In event based modeling the language as well as the databases need to know events. Some tasks may contain a description of the behavior of a "decision maker"…it's important to find the right degree of user intervention.
A task is like a scene
Tasks are the basic building blocks of a quant innovations (as scenes are the basic building blocks of a story). If the tasks don't work (solve problems and attract users) the innovation doesn't. It must offer a clear shift (a change) throughout its flow. If it doesn't the programming language, the data structure, the models, algorithms, event model…may be brilliant…it will not sell.
Focus on tasks! A task must move value states in sequences (create workflows). From instrument values to portfolio values…from prices to risk spectra…from VaR Deltas to the portfolio VaR and the contribution VaR of instruments…from the counter party portfolio nettings to Value Adjustments…
Get the users hooked
The tasks need to overcome internal conflicts (offer the required regime switches…say, to models that can treat negative interest rates correctly…) and handle possible external conflicts of, say, users (say, front office vs. risk quant…investment manager vs regulator…).
If the task has a time dimension it must move objects and actors…
The quant innovation must not manipulate users, but motivate them…to test extreme (pathologic) cases, validate models and methods, walk through the what if scenarios, back and stress test…
In one of the next posts, I'll come to workflows (sequences of tasks).
