Inventing The Next Business Programming Language

Inventing the next
business programming
language.
1Wednesday, September 25, 13
Inventing a programming language is probably an exercise in futility.

You have to be slightly mad to attempt such a thing without a sponsor.

1962 to ?
• Wrote my first computer program in 1962
as a student at University of Michigan
using a language called "Michigan Algorithm Decoder" (MAD).
• MAD was similar to Algol, but it was extensible.
.You could add data types.
.You could add prefix, postfix, and infix operators.
.You could overload arithmetic operators.
• It was a good language for writing domain specific languages (DSL).
. Students routinely wrote obvious extensions
. . like date arithmetic, vector arithmetic, matrix arithmetic,
. . list operations, set operations, pattern matching.
• In some ways, we really have not come all that far since 1962.
Speaking of MAD.
I wrote my first computer program in 1962 at the University of Michigan in a language called
MAD.
MAD stood for “Michigan Algorithm Decoder”.
MAD was like Algol, but it was extensible.
You could write your own plug-ins for the compiler in order to add new datatypes.
It was a good framework for writing domain specific languages.

We have not come all that far since 1962
in terms of capability and readability.
• MAD extensions were written
in a Macro-Assembly language
following an extension framework.
In effect, they extended the compiler.
• Classes in object oriented languages
(C++, Java, C#, Objective-C, Python, Smalltalk)
. . . don't really extend the compiler.
• But the capability provided is almost the same.
Object oriented languages don’t extend the compiler, but they do provide ways to add
datatypes which extend the capability of the base language in a way that feels like an
extension to the language. In fact, you cannot really beneﬁt from an object oriented language
until you learn many of the basic class libraries.
In my opinion, the state of the art in programming languages has not progressed much since
1980.
That is approximately when Smalltalk and C++ were invented.
Our industry reinvents the same solutions over and over.
I ﬁnd that frustrating, and that makes me mad!

Algebra-Based Notations
Program code is no more readable now than it was in 1970, and that makes me mad.
Why is program code hard to read?
The mere fact we call it code, says something.
We call it that because we translate from English to algebra.
Most of the popular computer programming languages have a notation that is basically a kind of algebra.
The reason they look that way is that early computers were primarily used for computation
and algebra is a time-honored way to express computations.

Inventing the next
business programming
language
To program a computer,
use a
computer programming language.
To program a business,
use a
business programming language.
But, business programming involves very little computation.
So a computation-oriented language actually gets in the way.

Coordinating Actors
Programming a business process involves
coordinating the work of a set of collaborating actors.
Some of the actors will be people, some will be organizations, some will be applications,
and some will be robots.
In fact, most business applications are proxies for speciﬁc business units.
Examples:
- Customer Relationship Management
- Accounts Receivable
- Purchasing
- Order Fullﬁllment

Program the business,
not the computer
• You want a programming framework
to solve the problem,
not become the problem.
• Frameworks such as JEE tend to become the problem.
• A business programming framework should eliminate
machine-oriented questions from the problem space.
• Persistence, messaging, resource allocation and tracking,
system monitoring, numeric precision, test conﬁguration
. . . can all be handled automatically
and eliminated from the problem space.
All these things are about the
hardware, not the business.
When I am programming a business process,
I want a framework that helps me program the process
and that does not divert me into solving unrelated problems.
I want the framework to solve the problem, not become the problem.
Hardware-driven problems like persistence, allocation, tracking, monitoring, numeric
precision, and messaging can all be automated and removed from the programmer`s
problem space.

That is enough about Why.
(Motivation and Requirements)
Let’s move on to How.
(Architecture and Design)

Notations + Runtime
• A programming language
is a set of coordinated notations
with a runtime framework.
• The trick is to make each notation
expressive and readable
while simultaneously eliminating any discordance
between the notations.
• Coordination of the notations requires
a shared ontology
and favors seamless connections.
The
notations
speak to
the runtime.
What does a programming language do?
It speaks simultaneously to the programming framework and to the programmer.
It must be both machine-readable and human readable.
In terms of structure, a programming language generally has several notations that serve
different purposes. There are usually at least three: one for procedures, one for nouns, and
one for formatting.
Cobol adds specific statement sets for configuration, identification, sorting, and reporting.
A Java programmer typically needs to know Java, JavaDocs, Java decorations, property files,
HTTP, HTML, some template notation, and several XML-based notations. One of the things
that makes Java hard, is that these notations are not very well coordinated. You have to write
a lot of bridge code to force coordination.

Notations
• A notation is a means for representing knowledge.
• Business programming requires notations for
• plans
• procedures
• protocols & dialogs
• views, forms, documents
• nouns: entities, supertypes, attributes, categories
• data in transit
Process
User Interface
Schema
A programming notation is a way of representing knowledge
in a way that is both machine readable and human readable.
You need notations that represent process knowledge.
You need a notation for showing data and system documentation to the user.
You need a notation for documenting noun relationships.
Almost every language has a standard notation for representing data in transit.
Data in transit is strongly coupled to the data schema.
So I treat these two notations as being in the same knowledge dimension.

Language Design Principles
• Each notation should be expressive and readable.
• Each syntax should be as simple as possible.
• A language should coordinate notations
in an obvious way.
• The framework should not become the problem.
• Common problems with known solutions
should be delegated to the framework.
This is a summary of the design “principles”.

Well ... alright ...
I want to see the plan.
http://www2.gibson.com/News-Lifestyle/Features/en-us/beatles-you-say-you-want-a.aspx
When you are reading legacy code, it can be difficult to discover the plan, the workﬂow, of the system.
Most programming languages have no notation for expressing plans.

Assembly, Dis-
http://image.motortrend.com/f/features/travel/
1301_1812_miles_in_three_2013_honda_accords/41859496/Honda-of-America-
Manufacturing-assembly-line.jpg
A modern automobile has something on the order of 30,000 parts.
How do you plan something as complex as an automotive assembly line?
There is a technique called “Disassembly” where you consider the fully assembled vehicle
and work backwards.
Example: The easiest thing to remove might be the wheels, doors, hatches and windows.
The doors in turn can be disassembled and so on.
The basic idea is that you start with the goal,
deﬁne prerequisites (subgoals),
and work backwards until you have a complete plan.

PLAN FRAME - ROOT
Goal: Bake me a cake per recipe.
Preconditions:
. Oven is preheated to recipe`s oven-temperature.
. Cake-pan with batter prepared per recipe
is in the oven.
Actions:
. Smart-Oven: Bake per recipe`s bake-time.
This goal
bakes the cake
but does not
decorate it.
Dictionary: Recipe vocabulary.
. Recipe attributes include ingredients, oven-
temperature, bake-time.
Build a plan-tree
by back-chaining the preconditions
to reach subgoals with no preconditions.
The action executes after the preconditions are
met and produces the goal condition as a result.
A business process needs a notation that expresses work ﬂow.
Business operations process work tasks in parallel,
and they are distributed across many actors.
Again, the easiest way to create a plan is to start with the end-goal
and work backwards from there.
The three elements of a plan frame are
- goal: the post-condition that will be true after the action executes.
- preconditions: the prerequisites that must be true before the action executes.
- action: a transitional action that moves the plan into the post-condition
(The action is performed by some role. In this case, the role is called “Smart-Oven.”)
The preconditions and action are both optional.
- If there are no preconditions, the action can execute immediately.
- If there is no action, the plan frame provides a way to summarize a set of conditions.
Dictionary frames identify nouns and their relationships.
When the nouns are known, natural language can be translated
into almost any machine-executable language. (next slide)

ENGLISH ==> JAVA
. Smart-Oven: Bake per recipe`s bake-time.
package actors;
import nouns.JobTicket;
import nouns.Recipe;
import nouns.Measure;
public class SmartOven extends Actor {

public JobTicket bakePerRecipeBakeTime( JobTicket ticket
, Recipe recipe
, Measure bakeTime
){
. . .
return ticket;
}
}
A delegated task is a work-order.
We do the accounting in-line.
This notation may look like pseudo-code but it is fully translatable and executable.
The trick is to recognize that
any English language sentence can be translated into a method signature
by converting the sentence to camel-case
and translating the nouns into an argument list.
Here is an example.
In this case, the English statement is translated into a Java method skeleton.
In natural language, a noun points to an entity or attribute in some world.
In other words, a nouns marks something that may be a variable.
The world might be the real world, a business, a simulation, or a game world.
Aside: A business is very similar to a multi-player game.

WE CANTAKE ALGEBRA OUT OF PROGRAMMING.
BUT WE CANNOTTAKE PROGRAMMING OUT OF
PROGRAMMING.
NOUNS MUST HAVE ANTECEDENTS.
Goal: Bake me a cake per recipe.
Preconditions:
. Oven is preheated to recipe`s oven-temperature.
. Cake-pan with batter prepared per recipe
is in the oven.
Actions:
. Smart-Oven: Bake for the recipe`s bake-time.
temperature, bake-time.
At this point, the words in red are not known nouns.
We can take the syntax constraints out of programming.
But we cannot really take the programming out of programming.
Just as a Java critic will tell you when a variable is undeﬁned,
a critic dealing with natural language will need to inform the programmer
when nouns in the sentences lack antecedents.
When nouns lack antecedents,
there is no simple way to populate their values from the context.

PLAN FRAME 2
Goal: Oven is preheated to recipe`s oven-temperature.
Preconditions:
. Oven thermostat set to recipe`s oven-temperature.
. Oven is heating.
Actions:
. Smart-Oven: Chime when oven is preheated.
Dictionary: Oven attributes.
. Oven attributes include oven-temperature, state.
. Oven state categories include off, heating,
preheated, baking.
. Temperature is a measure.
. (By convention, oven-temperature is a temperature.)
After we enter this dictionary frame into the ontology,
the critic will know that these words are nouns.
They may then have missing antecedents in other frames.
This plan frame identiﬁes the preconditions and transitional action needed to achieve one of
the preconditions that was in the root plan frame.
Since this concerns the oven, we have to deﬁne an oven entity and its attributes.
The oven-temperature is, by convention, a temperature.
We declare a temperature to be a measure.
Measures are built into the framework
because every number in a business context is actually a measure.
Words that name colors are like enum`s. They are in a set of allowed values for an attribute.
The allowed values basically categories; so that is what I call them.

PLAN FRAME 3
Goal: Cake-pan with batter prepared per recipe
is in the oven.
Preconditions:
. Batter is prepared per recipe.
. Cake-pan is greased per recipe.
Actions:
. Mixer: Pour batter into cake-pan.
. Mover: Move cake-pan into oven.
Dictionary: Kitchen Equipment.
. Kitchen attributes include oven, cake-pan.
This plan frame also identiﬁes the preconditions and transitional actions
for a precondition that appeared in the plan`s root frame.
In this way, a plan-tree of almost any complexity can be built and executed.
I use the word plan-tree because the graph for the plan is mostly tree-shaped.
However, multiple frames may share a precondition,
so the graph may be more like a precedence chart than a tree.
The correct term is “directed acyclic graph”.
However, the graph is tree-like in so far as there will be “leaf” nodes when the plan is
executing.
The leaf nodes have no unsatisﬁed preconditions,
so their actions may be executing in parallel.

PLAN FRAME 4
Goal: Batter is prepared per recipe.
Preconditions:
. All ingredients are assembled on counter.
. Mixing equipment assembled on counter.
Actions:
. Mixer: Mix all of the recipe`s ingredients.
Ingredients assumed to be attribute of recipe.
The second precondition has no known nouns.
Fix-up nouns:
Dictionary: Kitchen Equipment.
. Kitchen attributes include oven, cake-pan, counter.
The word ingredients is a slight problem in that there is no obvious antecedent.
But when the critic learns that “ingredients” is an attribute of a recipe,
it can forgive and forget.
However, the second precondition has no known nouns in the dictionary frames we have seen
so far.
The critic will complain if a statement has no known nouns.
That kind of statement assumes a hidden global state.
In this case, we can ﬁx things up by adding an appropriate dictionary statement.

Role-Action Frame
Role: Mixer.
Action: Mix all of the recipe`s ingredients.
. For each ingredient in the recipe`s ingredients:
. . Add ingredient to the batter in the mixing bowl.
. . Stir until ingredient is blended into batter.
. Stir until batter is smooth.
To: Stir until batter is smooth.
. Beater: Beat the batter on high for 90 seconds.
“Stir until batter is smooth.” has no known nouns.
Fix-up nouns:
temperature, bake-time, batter, cake.
In the previous frame, we had an action statement
Mixer: Mix all of the recipe`s ingredients.
This action is deﬁned by the procedure in this role-action frame.
The procedure labeled “Action:” is part of the role`s public interface.
The procedure labeled “To:” is an internal procedure.
The word “ingredients” indicates a collection because it is plural.
The form “For each <item> in <collection>:” is the only iteration block in the Hum language.
However, recursion is permitted within a role`s private actions.
The public interface is a speciﬁcation. It is required. Everything else is a suggestion and could be changed.

Delegation
Role: Mixer.
Action: Mix all of the recipe`s ingredients.
. For each ingredient in the recipe`s ingredients:
. . Add ingredient to batter in mixing bowl.
. . Stir until ingredient is blended into batter.
. Stir until batter is smooth.
To: Stir until batter is smooth.
. Beater: Beat the batter on high for 90 seconds.
Role: Beater.
Action: Beat the batter on level for time.
. Set motor-speed to level.
. Lower beater head.
. Turn motor on.
. Timer: Wait for time.
. Turn motor off.
Roles may delegate individual steps to other roles.
Note that the same actor may perform both roles.
The Resource Manager can optimize utilization
by assigning the delegated task back to the same actor.

Recursion
Role: Beater.
Action: Beat the batter on level until smooth.
. Set motor-speed to level.
. Lower beater head.
. Turn motor on.
. Test batter for smoothness periodically.
. Turn motor off.
To: Test batter for smoothness periodically.
. Timer: Wait 10 seconds.
. CV: Assess batter smoothness giving yes-no.
. If yes-no equals no:
. . Test batter for smoothness periodically.
In the prior slide we had an open-loop process
that simply beat the batter for 90 seconds
and assumed it would be smooth after 90 seconds of beating.
In this version, we refactor the Beater action to get a closed loop via a recursive call.
For this to work, we assume there is some way to sense that the batter has become smooth.
Note that we could optimize tail-recursion
when the recursion is in a private method
and the recursive call is in the last statement of the method.
In general, recursion of any complexity is allowed
and it is the programmer`s responsibility to assure that loops will terminate.

User Interface
Another kind of process knowledge is often seen in user interfaces.
For example, when the user does this, do that.

Dialog: He-said. She-said.
Pattern ==> Response.
Pattern :: String with wild-cards and/or slots.
Response :: (String) + (Procedure).
Romeo: O, wilt thou leave me so unsatisﬁed?
Juliet: What satisfaction canst thou have tonight?
A client interface contains sets of production rules.
The basic idea is given-when-then.
Given: You are in a certain contex.
When: You detect a certain pattern / speech-act.
Then: Produce the following response.
There is an ancient way of recording dialogs.
It is the script of a play.

Dialog Frames
Dialog: Hotel Desk Services.
Context: Clerk avatar responds to player.
Player: I want to register. (These patterns produce same response.)
Player: I have a reservation.
Player: I would like a room.
Clerk: Please place your palm on the register.
Player: Places palm on register.
Clerk: Thank you. The room`s door will respond to your palm.
. Rooms: Bind player`s palm to room entry authorization.
. (Dialog frames can also invoke goals.)
Player: Hello. (Scribe translates several gestures to this pattern.)
Clerk: Can I help you?
Player: I am ready to check-out.
Clerk: You can check-out, but you cannot leave.
Hotel California
Here is a dialog frame containing several vignettes.
When this context is active,
the Dialog Agent will attempt to match user utterances
to one of the vignettes in the order given with the frame.
The first vignette to match will execute.
Note: There may be a stack of contexts because users sometimes backtrack to a previous
context.
In this case, the first vignette has several ways for the user to say the same thing.
This is a simplified example.
The full notation mimics everything in the AIML “ALICE” chat-bot programming framework.
Modern chat-bots are getting closer and closer to passing the Turing “intelligence” test.

View Frames
View: Site-Registration.
!!Site Registration
Display Name: [display-name]
E-Mail: [e-mail]
Role: [role]
Description: [description 5]
Send discussion summaries:
. Choose digest-preference immediate, daily, weekly, never.
(1) Immediately (2) Daily (3) Weekly (4) Never.
Dictionary: User attributes.
. User attributes include role, e-mail, display-name, description,
digest-preference.
. Description is a text.
. Digest-preference categories include daily, weekly, never, immediate.
. User role categories include member, moderator, editor, admin.
. Admin is shorthand for administrator.
widgets
radio buttons
User: I want to become a member.
System: Please fill-in our registration form.
. Enter data from Site-Registration view.
I’ve used a number of mark-up notations in my career.
I think that HTML is the most awkward and intrusive of them all.
I wanted a notation without a lot of intrusive syntax,
so I designed my own mark-up notation for views and documents.
It is derived from wiki mark-up.
I simply extended a wiki mark-up to include widgets and tables.
However, I do not currently have any styling. No fonts, no colors, no fancy layout.
Styling can be added; but I am currently undecided about when, where, why, and how to do
that.

UI is type-aware
View: User.
!!Site Registration
E-Mail: [e-mail]
Role: [role]
Dictionary: User attributes.
. User attributes include role, e-mail, display-name, description,
digest-preference.
. Description is a text.
. Digest-preference categories include daily, weekly, never, immediate.
. User role categories include member, moderator, editor, admin.
. Admin is shorthand for administrator.
category ==> pull-down
text ==> text-area
The programming framework should not waste the programmer`s time on the obvious.
For example: In this frame . . .
[1] We want the labels to be right-aligned.
[2] The role attribute is a category. Therefore a pull-down widget is appropriate.
[3] The description ﬁeld is a text. Therefore a text-area widget is appropriate.
[4] In this case, we specify that we want up to ﬁve lines of text to be shown -- overriding any
default.
[5] However, interpreting radio buttons might not be so obvious.
So, some advice is inserted into the view code.

Dynamic View
View: Site-Registration.
!!Site Registration
E-Mail: [e-mail]
Role: [role]
. When role equals admin:
[pane: Administrator-Data]
. End When.
Sometimes we want the view to change depending on user inputs.
This slide shows a potential notation design.
. . .
. When role equals admin:
[pane: Administrator-Data]
. End When.
. . .
When the role attribute has the value “admin”,
the view-controller code with display the pane for administrator data to be entered.
Otherwise, that pane is not seen.

Scribehttp://itcomp.org.ua/?page_id=232
http://itcomp.org.ua/?page_id=232
Earlier we mentioned the Scribe.

Translate User Gestures
The basic purpose of the Scribe is to decouple dialog vignettes from sensors.
In today`s world the same user gesture may be expressed in many ways.
When I review user interface code,
I often ﬁnd that the code is tightly-coupled to speciﬁc sensors.
The code to translate sensor inputs to user gestures is mixed with the dialog logic.
This violates the principle that a code module should serve a single purpose.
It also adds noise that makes code harder to understand.
As often as not, the users will ask that the same gesture be invoked in two or three different
ways.
The Scribe interprets sensor inputs
and translates a user gesture into a pattern that appears in a dialog frame.

What were you thinking?
http://icdn3.digitaltrends.com/image/eeg-headset-595x335-c.jpg
http://icdn3.digitaltrends.com/image/eeg-headset-595x335-c.jpg
Someday, the scribe might even know what you are thinking before you do.

Missing
I have not attempted to tell you everything.
That would take several hours.

Missing But Obvious
Procedure Blocks
If
OrIf
ElseIf
Assignments
. . . giving ______.
Values are immutable.
Mark-Up
*Bold*
_Underline_
~Italic~
More Widgets
[pane: <name>]
[link: name | url ]
I’ve left out some obvious things and a few not so obvious things.
But given what I’ve shown you so far, most of you could ﬁll-in the missing bits.
A not so obvious thing concerns value assignments:
[1] Following the example of COBOL,
the convention is that a computed value appears after the word “giving”.
[2] Following the example of Erlang,
I’ve decided that values passed to an actor should be immutable.

Architecture
www.arcosanti.org
http://www.arcosanti.org/sites/default/ﬁles/images/w20080614tt006_0.jpg
A programming language speaks to a framework.
A framework has an architecture.

World
base
Bookkeeper
Runtime Components
Resource
Manager
Messenger
Plan
Supervisor
Dialog
Agent
Monitor
Actor
Actor
Actor
Black
board
Client
Scribe
Here is the architecture.
The Client connects to the Scribe;
the Scribe to the Dialog Agent.
The Dialog Agent triggers plans and actions.
Plans are executed by the Plan Supervisor.
Actions in plans and dialogs are assigned to actors by the Resource Manager.
The Resource Manager hands resource utilization job tickets to the Bookkeeper.
Actors check-in with the Resource Manager and tell it which roles they can play.
The Dialog Agent maintains a blackboard cache
with the noun values that have been seen so far in the dialog.
The blackboard persists noun values on a temporal database which I call the World Base.
The World Base tracks all the data that the enterprise produces
and purges data when the retention rules ﬁre.
The Messenger connects everything together. It is part of the backplane.
The Monitor catches business exceptions
(mainly business resource problems and cancelled plans).
And also provides work-in-progress statistics.

Resource R1
measure M
was utilized by
actor A1
in role R2
while performing
action A2
servicing job J.
Bookkeeper
http://commons.wikimedia.org/wiki/File:The_bookkeeper_by_van_Dijk.jpg
http://commons.wikimedia.org/wiki/File:The_bookkeeper_by_van_Dijk.jpg
This is one of the Bookkeeper`s actions.

Bookkeeper
Out-of-the-box, the bookkeeper
tracks resource utilization, not monetization.
Utilization is tracked by
job ==> client, vignette, plan frame
actor - which actor
role - acting in which role
action - performing which action-statement
resource ==> type, source (inventory / pool)
The Bookkeeper tracks resource utilization
across a number of dimensions
for cost accounting purposes.
Resource utilization is tracked in physical units of measure.
Each enterprise will plug in its own modules to price or cost the resources.

WorldBase (Enterprise Memory)
http://www.gameclosure.com/blog/wp-content/uploads/2013/03/memory-splode.jpg
(entity, attribute: tp, value)
{ (entity, attribute, tp: value) }
http://www.gameclosure.com/blog/wp-content/uploads/2013/03/memory-splode.jpg
The basic idea behind a temporal database is that the database
tracks the time-period for which the value was valid.
Here, time-period is called tp to keep the tuple short.
The ﬁrst tuple represents the current value of an attribute,
the second tuple represents the history.

Records Retention Rule:
Don’t waste time
deciding what to persist,
when, where, how.
Persist everything now.
Decide when to purge.
I have spent many hours reviewing Java code.
And what I saw made me mad.
A very large percentage of the lines of code were devoted to the persistence layer.
That kind of coding is pure grunt work.
Programmer time was and is being wasted deciding what to persist, when, where, and how.
But that kind of coding has well known patterns.
Therefore it can be automated.
The programming framework should just do it.

Automatically record when:
•User / Client says something.
•A goal is satisﬁed.
•An action is started or completed.
•A message is sent or received.
•Actor checks-in or checks-out.
Basically, you need to record business events
and know that events represent changes in state.

Persist Now Purge Later.
•General Rules:
•Keep asset data indefinitely.
•Purge revenue & expense events
after 7 years.
•Purge dialog unrelated events after ?
•Record purge rules in
ontology or world-base configuration?
Enterprise records retention rules are primarily driven by tax regulation and common sense.
Some enterprises will want to keep certain kinds of data longer than others.
When in doubt, keep the data for the life of the enterprise and its legal obligations.
Comment:
- I experimented with two ways of representing retention rules.
One adds annotations to the statements in frames and makes the purge rules part of the
ontology.
The other uses a specific notation in a configuration file.
Each one has specific usability problems.

Calculator
I grew up with slide rules. They give you an appreciation for accuracy and precision.
Curiously, most computing frameworks do not track accuracy and precision.
Generally the answer you get has good accuracy but false precision.

Measurement
In business, there is no such thing as an integer or a real number.
Those concepts belong to mathematics.
In business, numbers are all measurements of some kind.
Measurement quantities always have some degree of precision.
Accuracy is a separate issue
determined by how you calibrate your measuring devices
and how you train your operators.

Fuzzy Arithmetic
When you do arithmetic with measurements,
you are really operating on distributions.
You can get the resulting distribution
by performing the arithmetic over random samples
on the incoming distributions.
(Monte Carlo technique)

Unit Of
Measure
Measurements have a unit of measure.
One software system lost track of the unit of measure and sent a billion-dollar spacecraft off
course.
This is another detail that the calculation framework should handle.
Physical units of measure have constant conversion factors.
Monetary units of measure have conversion factors that vary over time.

Messenger
HTTP
JMS RPC
REST
XMPP
SOAP
XML
SSL RSA
JSON
MQ
WSDL
JINI
SAML
FTP
EDI
BPEL
Enterprise systems require a way for distributed actors to communicate.
If you program in Erlang, you have a built-in distributed messaging system.
If you program in Java, you typically have to do it yourself with relatively low level code.
Typically, you ﬁnd yourself dealing with several of the protocols named here.
That means that the framework has become the problem.
I had a lot of hope for JINI, but JINI got waylaid.

Authentication
Authorization
Privacy
Non-repudiation
Guaranteed one-time
in-order-sent delivery
Logging
Replay
Functions
The programmer should not be exposed to all that communication protocol detail.
But there is more about actor to actor communication than serialization and transport.
In general, you need all of these functions also.
This is a big order and a lot of system-level problems which should not distract from the essential problem of
business programming.
It all should be handled automatically in the runtime framework.

Monitor
Monitoring is an additional concern that should not concern the business programmer.
Again, it belongs in the runtime framework.

Operate
However, business people will need to be in the loop when business exceptions occur.
Business exceptions occur when:
1. An action is overly delayed by a missing resource.
2. A client cancels a plan.
These cases must be routed to a trouble-shooting role.

Trouble Shooting
Business Exceptions
1. The component that detects a problem informs the Monitor.
2. The Monitor informs the affected plan`s Supervisor.
3. The Supervisor invokes a trouble-shooting goal. (a ﬁx-up plan)
Such goals tend to send actions to a trouble-shooter role. The
trouble-shooting actor will work to remedy the immediate problem.
http://www.gﬁ.com/blog/wp-content/uploads/2010/09/troubleshooting-1.jpg

Community
Text
http://will.illinois.edu/images/uploads/19341/community_mural-slide__slideshow.jpg
http://will.illinois.edu/images/uploads/19341/community_mural-slide__slideshow.jpg
Q: How many software engineers does it take to change a light bulb?
A: None. That is a hardware problem. It is outside of my expertise.
Q: How many psychologists does it take to change a light bulb?
A: Only one. But ﬁrst, the light bulb has to want to change.
I am a software engineer, not a social engineer.
The most important aspect of any language is the community that uses it.
Innovation is ultimately about providing both the means and the motivation.
Adopting a programming language is a major investment
and involves some risk. For those reasons, only early adopters will take such a risk.

Requirements
It has to work - to do what it claims.
Be better or faster or cheaper in some way.
Solve a problem better than incumbents.
Nice to have
be easy to learn
Social Features
Markets advance
along the path
of least resistance.
==> least learning.
To get into the environment,
a programming language has to meet these social requirements.

Sales Talk
Saves time and money.
Makes you more competitive.
Your competition is using it.
Solves the new problem better than incumbent.
To spread beyond early adopters,
a programming framework has to justify some sales talk. (rationale)

Killer Application
IBM says that the
killer app
for e-business . . . is
"an application
deployed over the Web
that makes it easier to
do the things you
already do."
http://searchsoa.techtarget.com/deﬁnition/killer-app
http://www.wired.com/dangerroom/2007/12/us-police-get-g/
Another thing that can get a framework into the environment (plant a seed)
is some “killer application” where that framework excels.

High Points
• Nouns are slots for values
==> translation is simple.
• Plan frames enable parallel processing.
• A framework should help solve the problem,
not become the problem.
• A language without a community is DoA.
This slide summarizes the main points you should remember from my talk.

The best way
to predict
the future is
to invent it.
-- Alan Kay
http://en.wikipedia.org/wiki/File:Alan_Kay2.jpg

If you follow
the crowd, you
will end up
waiting in line.
This is my personal slogan.
It is mostly good for planning lunch.

Questions
http://www.detourart.com/wp-content/uploads/2012/10/WATTS_TOWERS1871.jpg

Inventing The Next Business Programming Language

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (6)

Similar to Inventing The Next Business Programming Language

Similar to Inventing The Next Business Programming Language (20)

Recently uploaded

Recently uploaded (20)

Inventing The Next Business Programming Language