Firstly, it's not too difficult a word to define.Wikipedia seems to capture it quite well:
An agent's intention in performing an action is his or her specific purpose in doing so, the end or goal that is aimed at, or intended to accomplish. Whether an action is successful or unsuccessful depends at least on whether the intended result was brought about. Other consequences of someone's acting are called unintentional. Intentional behavior can also be just thoughtful and deliberate goal-directedness.In relation to computing, intentionality has at least a couple of specific meanings:
- Programmer perspective - for example a programme may or may not not behave as a programmer intended when they wrote the programming code.
- User perspective - for example if the results of operating a programme do not reflect the intentions of the user then the user experience is less than it might have been.
Intentional Programming is essentially an approach to computer programming that enables the programmer to focus as far as possible on achieving the outcome of what they intended and not focus on the process of achieving what they intended. Put this way, it can be seen that the history of computer programming is about increasing the level of intentionality by way of increasing abstraction. For example the word print in most computer programmes causes the production of printed output on a screen or printer - print captures the intention of a programmer at that point, and is an abstraction of a whole series of more primitive computer operations.
The fundamental feature of Intentional Programming is abstraction, reflecting its origins in the transition of Bravo to Microsoft Word. For years Word was more advanced than other word processors such as Word Perfect because it hid the formatting symbols, allowing users to focus on what they were writing rather than on formatting - so called WYSIWYG. As abstraction increases there is no reason why the programming language should not come to resemble normal language. For example, the phrase show me John Smith's latest serum level might be a phrase in a computer programme provided there is a mechanism for the computer to translate it into a correct sequence of actions and outputs.
There are a couple of consequences of this approach. Firstly, the need for programming environments (which are themselves based on domain specific programming languages) in which the elements and processes of particular domains are represented and can be manipulated. Secondly, the increasing possibility that non-programmers can instruct computers directly.
This second consequence isn't inevitable - domains and domain specific languages can be technical - for example a domain might be 'relational databases' with the associated domain specific language is SQL. But even here there are visual front ends to SQL which allow non programmers to extract data from databases.
A domain might also be one of a practice - such as clinical medicine, for which there are a number of domain specific languages of varying degrees of abstraction - MUMPS, HL7, Arden Syntax and ProForma. The latter allows end users (clinicians!) to understand, verify and directly manipulate the programmes which they are using, a potentially very valuable level of engagement and transparency. There is also the possibility of software that transforms system models into working software - the Model Driven Architecture approach. Some software claims to have implemented software factories or machines, but in reality this approach to software development is stuck at the wrong end of the Gartner hype curve.
The fundamental feature of Intentional Programming is abstraction, reflecting its origins in the transition of Bravo to Microsoft Word. For years Word was more advanced than other word processors such as Word Perfect because it hid the formatting symbols, allowing users to focus on what they were writing rather than on formatting - so called WYSIWYG. As abstraction increases there is no reason why the programming language should not come to resemble normal language. For example, the phrase show me John Smith's latest serum level might be a phrase in a computer programme provided there is a mechanism for the computer to translate it into a correct sequence of actions and outputs.
There are a couple of consequences of this approach. Firstly, the need for programming environments (which are themselves based on domain specific programming languages) in which the elements and processes of particular domains are represented and can be manipulated. Secondly, the increasing possibility that non-programmers can instruct computers directly.
This second consequence isn't inevitable - domains and domain specific languages can be technical - for example a domain might be 'relational databases' with the associated domain specific language is SQL. But even here there are visual front ends to SQL which allow non programmers to extract data from databases.
A domain might also be one of a practice - such as clinical medicine, for which there are a number of domain specific languages of varying degrees of abstraction - MUMPS, HL7, Arden Syntax and ProForma. The latter allows end users (clinicians!) to understand, verify and directly manipulate the programmes which they are using, a potentially very valuable level of engagement and transparency. There is also the possibility of software that transforms system models into working software - the Model Driven Architecture approach. Some software claims to have implemented software factories or machines, but in reality this approach to software development is stuck at the wrong end of the Gartner hype curve.
Model Driven software manufactories are intended to be largely the preserve of IT specialists, with some input from business users. Thre are however a small number of platforms in which the end user directly creates software. In a sense Microsoft Access was an early and successful attempt to let non-programmers create software - the NHS for example has many applications created in MS Access by clinicians. Iceberg might be seen as the present day equivalent. With many business activites being defined as processes, software like K2 (see K2 Studio) has a role to play.
Today's businesses are process driven, everything done in a business is a process, from making coffee to hiring an employee to auditing financial transactions. Thus it makes sense to extrapolate these processes to reusable definitions which can be controlled by software to ensure that actions are repeatable, auditable, monitored and predictable (ref)
The difficulty here, as experience testifies, is that there is often a lack of understanding or consensus in organisations about their processes. And no software on earth can solve that.
It is therefore difficult to capture intentions in software. This is true at all levels software performance, but most notably at the level of functionality. In relation to their capacity to reflect and fulfil user intentions the same question can be asked of all software applications whether it is an invoice processing system or a search engine - did it do what I intended it to do? The question is complicated by the fact that intentions are often shaped by an understanding of the software...
Related Post:
Widget by [ Iptek-4u ]
