The programming lifecycle is like a four stroke engine.
The programming lifecycle:
1. Program new feature, create.
2. Deploy, get everyone using it and counting on it.
3. Modify old feature, no longer new programming, much harder.
4. Abandon, prepare to replace.
abandon | | deploy
The four stroke engine runs on needs, each stroke-action meets a set of needs:
- Programming is a creative enterprise based on the needs of the prospective user; and on the knowledge, skill, philosophy, and input of the programmer.
- Then the program is deployed, users are trained and the program starts to get used.
- Once something is deployed, then it must continue to function as it is modified. It is modified by newly discovered needs found during use of the program.
- There comes a point where the needs of the users outstrip the ability of the programmers to make modifications. At this point the program is either officially or more often unofficially abandoned. It usually continues to be used but the users must wait for a new program to be written to meet their new needs.
Deploy and abandon are opposite actions.
Are program and modify opposite actions?
The path to hard AI is through the following sequence of development:
1. build a system for storing data – relational database development
2. build a system for processing data – object oriented software development
3. make it possible to process information as opposed to just data inside a computer program – endemes, fuzzy logic, and other technologies not yet developed.
4. make it possible to organize information – knowledge representation / ontologies etc.
5. figure out how to build soft A.I.
6. figure out how to build soft computational creativity (CC)
7. figure out how to get AI/CC programs to create programs (comps)
8. build limited lifespan ‘comps’ in two types (male and female) that reproduce, run, procreate, die and evolve with a lifespan of less than a day.
9. build interactive communities of comps
10. give comps either virtual physicality with real physical world interaction
11. make the comp virtual world rich and a good representation of the real world
12. empower comps to mirror other comps mental processes
13. arrange sub-communities of comps called ‘families’ to teach their ‘child’ comps over a period of time
14. build the comp virtual environment so that comps can repurpose pieces of it to affect other pieces (tools)
15. build comps so that they can create their own languages regarding he tools they create and other things in their environment
16. allow comps to become sentient
17. allow comps to create extra-familial communities with other sentient comps
18. allow comps to teach each other from generation to generation within these communities, allow them to control macro technology, factories, farms etc.
19. allow the most successful inter-reproducable lineage of comps to eliminate all others
20. teach comps about God and Jesus, allow comps to change their virtual world and the real world
21. allow comps to form large lineage based societies
22. allow comps to record knowledge rather than just teaching it directly from generation to generation, give them control of micro-technology
23. systemetize comp knowledge recording
24. give comps access to all science and philosophy
25. comps organize themselves into a smaller number of very large competing organizations
26. allow comps to control nanotechnology
Around level 16 we start allowing artificial intelligence to do things rather than creating it ourselves to do things. And we start allowing artificial intelligence to have more and more control of and independence in the real world.
At about level 36, hard AI is just as intelligent as we are.
This list implies that we are much much farther from hard A.I. that we think we are. Think of the amount of work that it has taken to build the object oriented Level 2, and the the Relational database Level 1. Now realize that that much work will be needed for at least the next ten levels. If each level takes the same time, since it took 70 years to build levels 1 and 2. At that rate we should reach hard A.I. (level 36) around the year 2650 AD.
I use the made up word endeme a lot on this site. It is a bridge between O.O. and K.R. Looking around the web for the use of ‘endeme’ I found the following quotes in Dutch which I converted to English using Babelfish:
(zonder hoofdletter hoor ik wijlen André Peytier nog zeggen, met hoofdletter betekent het Iridium!) en de me zelf cadeau gedane job titel: ‘President’.
(without case I hear late Andr Peytier say, with a capital means Iridium!) And made my self present job title. "President '.
[and made my]
vond dat met die verhuis dozen leuke actie, en de me is overal altijd agressief, niets nieuws, die jongens zitten thuis onder de plak.
found that those moving boxes fun action, and I was always aggressive everywhere, nothing new, those guys sitting at home under the thumb.
[and I everywhere]
Een muurschildering met de boom en de me to you beer is in diverse formaten te maken en zijn geschikt voor de normale en grotere babykamers
A mural with the tree and me to you bear is dealing in various sizes and are suitable for normal and larger nurseries
[and me is]
It seems that ‘en de me’ means something like and me, and I or and my in dutch with the ‘de’ being the beginning of a word somewhere later in the sentence.
There have been a number of previous attempts to work with information orientation:
- XML, lowest language
- Fuzzy logic
- Knowledge representation/ontologies
These are good tools and yet the toolbox is not big enough yet.
There has been some work done with information oriented architectures. Some quotes from around the web:
“Whether they realize it or not, software architects tend to adhere to one of two distinctive views of software: either a process-centric view or a data-centric view” – the problem with this viewpoint is that data and information are different and process is only one kind of information. Still, it is a useful perspective.
“Let’s trust our technologies to be sufficiently advanced to cope with the outcomes of our new orientation: information. Information is used by human beings for decision making annex action (behaviour). Making good decisions requires you to avail yourself of the clear meaning of that information. And meaning of information depends on its context … Therefore IOA requires information to be organised systematically : Information connected to its Context.” – This is the information by organized by context approach and is close to what I am trying to do. Organizing by context includes the following approaches:
- Relational databases (RDB)
- Knowledge representation (KR)
- endematic metadata
- object oriented structures (OO)
- XML/JSON etc
- intelligent contexts (AI)
The endematic metadata and endemes become a connecting usint between the lower level contexts (RDB, OO, XML) and the higher level contexts (KR, AI). Also from this site: “Systematically organised information naturally provides you with information of the clearest possible meaning. Contextual meaning, of course – which naturally develops on the fly; during use.”
“IOA is about being. IOA provides information to be acted upon, not a set of actions to be requested or used. It says, “This is what I am; make the most of it.” This approach provides freedom to the community to make use of that information as it sees fit. It encourages collaboration and enrichment of this information for the good of the community” – This is a sort of a community approach but just as importantly an approach to information based on what each member of a community wants to do with it. This is very important for information. One of the characteristics of information is that it should be formatted, arrayed, displayed, organized and queried differently by each member of the community. The writer then goes on to talk about ontologies. Important but not the whole story. What is left out is the information about what the ontologies are relating.
Sparkomatic’s Blog says some important things about information:
“the terms Information and Data are so closely related that they are very often used interchangeably without any serious negative consequences. So why do we really need to differentiate between the two? In situations such as a casual conversation it’s arguably harmless to mix those two ideas up, but when it comes to designing, developing and delivering critical Information Solutions to users it’s a much different story. In that case, our collective ability to establish and share a clear understanding of what characterizes an Information Oriented Architecture becomes not only critically important, but also practically very useful in doing the actual work of implementing solutions built on an IOA foundation.” – It is critical to understand the difference between data and information. He does not say why, but I agree with him. Hen he goes off the rails trying to describe the differences: “Data is mutable, while Information is immutable. Mutability – the ability to mutate, or change value – is really only a property of data, which is concrete and therefore can change. Information, on the other hand, is transcendent, and not immediately or directly realizable. It is merely an image or reflection of the data that it represents.” – Certainly deriving information from data is an important source, but it is not the onmly source for information. For example I could just tell you some information. My statement if stored is mutable. I could produce information from information. I coudl generate it randomly. I could solicit information from a user. They they could change their mind. A fraction of information is immutable. Much of it is mutable. “Information is Data plus Context. Take the numbers 5 and 7. Taken by themselves they are simply data values, but if we add a context to these values by labeling them as the final scores of the big game, then it becomes information.” – This part he gets right.
ASP.NET has a concept called ‘code behind’. That’s not what I want to talk about. I want to use it as an analogy for something else. First let my describe what ‘code behind’ is. Code behind is a system in which web user interface controls can be organized into web page files without including the functionality associated with those control in one file. and then putting the functionality associated with those controls in another file. This file is called the ‘code behind’ file. The advantage of this is that it helps separate presentation from business logic. So the business logic can be found and changed without affecting the organization of the screens it affects.
An analogy to code behind that I have just discovered would be something I call ‘information behind’. With information behind you would have the code that runs a screen in that second code behind file and you would have each variable, function, database field, member, and global variable contained in some sort of structure that identified them by some sort of string. For example your members could all be items in a Dictionary in which the keys were the variable names and the values were the variable values. DataTables and DataSets already do this more or less. You would have a similar structure with functions, in which you would have functions or delegates or something in a big Dictionary structure and you would run them by reference to their string names out of that structure. This approach would be analogous to the web page file. Lets call this a ‘code front’ file.
Then you would have the information program that manages the meanings and organizations and flows and so on of the application in ‘information behind’ files. These files would manage and use and work with the string labeled members and methods in the ‘code front’ files. You could characterize the data and the member contexts from the ‘information behind’ files and essentially run your program from an information oriented perspective. This would separate the information and data concerns.
Data semantics can do this for you. Then level 4 stuff can use the data semantics to do all sorts of things. You might even have a level behind ‘information behind’ etc.
Information can be thought of as data that has meaning. Digging around the web I found some thing that people seem to think are involved in meaning. Data can be supplied with meaning through:
– description – data semantics
– importance – endemes (seriousness)
– relationship – knowledge representation (causal)
– security – access/permissions
– logic/propositional logic/truth value
– grammar semantics/Chomskyan internalist semantics
– variables system
– text before and after it – “Words and sentences that occur before or after a word or sentence and imbue it with a particular meaning.”
These are mostly forms of context. The “theory of meaning” is discussed at http://plato.stanford.edu/entries/meaning/. Interesting keywords are meaning, context, importance, description, relationship, purpose.
Components of Meaning Endeme Set
Here is an endeme set regarding some implementable components of meaning.
ABCDEFGHIJKLMNOPQRSTUV|ltr Label Levels: Implementation Tech additional terms/description
A] (P)-S- |A. Access ..3.... Permissions security, role based security
[B]C- -I--L- |B. Bridges .2..... SOAP etc. Communication, interaction, channels, lines, dataflow
[C] |C. Community ......7 Agents Communities of agent - Level 7.0?
[D] -S- |D. *Description ..3.... Data Semantics Semantics
[E] -V|E. Events ....5.. <Event/verb>
-C-[F] -U-|F. Frequency 1...... Commonness,Ubiquity
[G] -L- -S- |G. Grammar ....5.. Syntax language
-D- [H] (O) -T- |H. History <ugh> past,temporal/time/date/timestream/timeline/change
[I] -P- |I. *Importance ..3.... Endemes Priority - weighting - Endemes - Level 3.0
-F- [J] -U-|J. Job ....5.. Function(,Use)
[K] -R- |K. *Kowl. repr. ...4... Knowledge representatn Relationship - Level 4.1 (or 4.0, 3.9)
[L] -P- -T-V|L. Logic ....5.. Propositional logic truth value, truth
-BC- -I- [M] |M. Making .....6. CBR Implementation,built,construction,internals
-C- [N]O- |N. Noun/object .2..... Objects <Noun>/category/object
-C- [O] |O. Origin ......7 Creation,Creator
(F) [P] |P. Process ...4... Workflow flow
A- -M- [Q] |Q. Quality .....6. Adjective,Modifier/Decorator
[R]S- |R. Relevance ....5.. Situation/setting
-M- [S] |S. Statistics 1...... Statistical measures median/mean/mode/spread
[T] |T. Textual pos ....5.. textual position, text before and after it
-P- [U]|U. Use .....6. Purpose, roles
-G- -M- -U[V|V. Variables .2..... Variable system gaming/toy/universe model description
ABCDEFGHIJKLMNOPQRSTUV| 2332632 - 2 or 3 at each level except A.I. where meaning is the focus
Levels are: 1)R.DB., 2)O.O., 3)D.S., 4)K.R., 5)A.I., 6)C.C., 7)C.o.A.
Build a data structure optimized for how you know you are going to use it.
- how is it keyed, how are you going to access it?
- if you don’t know the best way to design it, start with a sub-optimal solution until you write more code.
- sub-optimal often means a group of lists or dictionaries of primitive types which operate in synch. Then you will eventually see that you need one two or more classes to keep the primitives in and refactor optimally based on your needs.
Build things at least twice, preferably three times
- the first time to understand the requirements.
- the second time to figure out the best design.
- the third time to do the implementation.
If you build things in a generic way so that they can be unit tested, they some of the things you build will be reusable in the second and third iterations.
Draw ERD’s to understand the database
An entity relationship diagram is a diagram showing how tables in a relational database relate. The boxes are the tables and the line between them are the relations. ERDs are like having a map to learn how to get around a city.
- use crows feet for the relations.
- ignore types but include each column name, key name and table name.
- make the table boxes 2 inches (or 5 cm) wide.
Draw ‘calling’ trees to understand a large code base
They are like having a map to learn how to get around a city.
- draw it so that the callers are on the left and the called methods are on the right.
- use arrows to indicate non-direct calls (like event invocations, web service calls etc.).
- the step through debugger is your friend in this.
Estimate a project at 4 x (new db columns + new db tables + information characteristics + relevant target fields) hours
- I just did a project with 22 columns in 4 tables, 12 characteristics, and 22 target fields in about 260 hours.
- the phases were 1) prototypes and requirements(10days), 2) design document(1day), 3) convert to production quality code (5days), 4) finish production code(10days), 5) convert to using web services(4days), 6) testing(1day), 7) deployment(1day) ~= 260 hours.
- make the estimate 5 x instead of 4 x for a kind of program you have not written before.
- If you do not get the project done within the estimated time, bump that factor of 4x or 5x up to what it needs to be for your experience level for succeeding projects.
Useful items to have in documents are:
- WHY. why the customer need this and how they will use it
- REQS. requirements.
- OODD. object oriented design.
- INFO. information analysis and design.
- UISD. User interface layouts and story boards.
- RDB. relational database design.
- NETS. networking and integration needs.
Depending on the size of the project these could be in one or multiple documents. Here is how these items relate:
/ \ / \
\ / \ /