(warning: long, essay post)
Today I feel centered. Not balanced, not inverted, but centered. It's been a long time since I've been in the zone. My last recollection of being in this beautiful state of mind was in the Spring and Summer of 1997. It's been some time and I hope this moment has some durability.
Sales samurai Brian Tinkler posted a great note here. Brian's been instrumental in the Milwaukee area in spreading the .Net word, in organizing community, and fostering communications and learning among the developer (.Net) community. He contributes to the betterment of the community. I've been a resident of the Milwaukee area all of my life even though I have worked on Wall Street, spent considerable consulting time in the San Francisco Bay Area and in Boston and traveled considerably. I have found that the Milwaukee market did not provide any intellectual incentives so I commuted on a weekly basis to other locations for consulting work. On the surface, this is a science-poor community. But I'm now beginning to find that there are others in the Milwaukee area like me who want and expect more. This is not an elitist perspective, but rather a call to arms: learn something today that you didn't know yesterday that will benefit both you and those around you.
Etiology of Centeredness
As the head of research for JJBR, I constantly have a number of topics to organize and follow. Because all work done through JJBR is after-hours activity, i.e. all members have real jobs that consume a great deal of their time, it is imperative that we, individually and collectively spend our time wisely. While we may joke or goof around in our posts and in our conversations, we are serious about the work we do. We live by a few simple tenets. Among them are:
- Forward looking social responsibility: What would our children and their children say of our work in the coming years? No member of JJBR wants to look at research performed and wonder 20+ years from now, why we couldn't advance the science of computing or mathematics or other disciplines. The advancement may be public or private, but nonetheless it is advancement.
- Challenge the expert: Among the public and termite members of JJBR, the strengths and weaknesses of the group are constantly in motion. It is critical to the success of the team that we learn from each other. Sociologically, we constantly challenge the leadership of the expert(s) in a given discipline. This is not an exercise in dethronement, but rather a ritual of enrichment. If the expert cannot defend a position, cannot explain a common practice in the discipline (with the emphasis on explain, i.e. the dissemination of information in a usable form for the audience), or has gaps in their knowledge, the challenge to that individual is to improve their base of knowledge and understanding.
- Standards and practices: Everyone holds everyone else within JJBR in high esteem. I hold fellow members to a standard and expect them to hold me to a standard. As we practice our disciplines and discover new materials, there is mutual understanding. We all improve by our practices and the standards that we set.
- Multidisciplinary first: All JJBR members must bring to the table a set of disciplines that, while they may appear disjoint, provide for some cohesive view of the world. I am a software developer, but I spend considerable time working in mathematics in Graph Theory (some Ramsey Theory), Number Theory, Theory of Computation (and computational complexity theory) and other branches of mathematics. Additionally, I spend much of my time in cryptology, specifically in theory and cryptanalysis. I devote a great deal of time to AI, or as we refer to it, Computational Intelligence. I'm fond of GP and EC and some GA, but extensively practice Exparative Modeling (more on this below). Any study of computation without a study of linguistics is foolishness, so I spend time in this as well. My Chomsky readings, particularly "Aspects on the Theory of Syntax" are time consuming because while the material is dense and there is a great deal of knowledge that is conveyed in this and other Chomsky works, his written word is not engaging (with apologies to Dr. Chomsky). All members of JJBR have overlapping footprints like mine.
Rabbit Holes
This is the fun part. Much of what I'm chasing intellectually at the moment takes me down some very deep rabbit holes. Let me share the first ten feet of depth with you in a few of these ATB areas. Warning: There may be a little rambling here and possibly a little incoherence, but I must retain, in the words of the lower-cased one, my blogness (transparency of character and purity in spontaneity).
I agree with this post that programming languages have a short history and have not had any revolutionary advancement recently. I especially enjoyed the history as I'm a fanatic about the history of mathematics. The first order logic (and lambda calculus) as prescribed by Church and others provides the basis for many of these languages. I think that the current notions in computing that allows for the construction of software in the absence of program verification in the manner of Hoare Logic or other forms of provability (NOT TDD) is reckless. While the motivations for TDD are noble, it would be unnecessary if development environments allowed for proofs and program verification. It provides the practitioner (developer, architect, designer, or otherwise) of computing environments with difficult, if not impossible quality constraints. Read some of the old writings of the past from Dijkstra and others and compare them with computing essays of today. We are today still in a state of disarray, i.e. we still haven't progressed on this topic. The notion that we attempt to practice simultaneously OO, SOA and AOP (all of which are useful, not holistic and definitely insufficient) is only a simple indication that we have not taken the time to understand the significance of the role of the science of computing. That coupled with misaligned financial incentives and the demand for production software leave us with the current state of affairs.
I think that the competent community of compiler constructers (some alliteration for the day) is much too small. I love the writings here. JJBR is working on EC models for competitive compilers. This is in an EC where each agent has the core compiler primitives (CSG, NFA, AST, etc.) and is allowed to evolve competitively in an environment of evolvable problem spaces (most NP-Complete and co-NE). How do the compilers evolve in capability where agents using them evolve programs. This sounds like crazy talk, but it provides a view on some gaping insufficiencies in many current theories and implementations. Are functional, imperative and logic programming only a small subset of evolvable collateral? What is the long term impact of side-effects in imperative languages in a large swarm environment? Read about the honey monkeys here for a taste of how we begin to think about EC. If we hang out in open computing land we can see easily: Haskell, Ruby, Lisp, Python, C#, Java, Scheme, APL, Algol, Smalltalk and the list goes on. These are the motivaters. In this context, Kozen, Aho, Hopcroft, Ullman, Milner and others are the inspiration. Koza, Goldberg, Holland, Brooks, Langton and many others are the enablers.
Language and Natural Language Processing are making the rounds in the media. It seems Google has an initiative to study 20 billion words and make some sense of the collective knowledge. Not to be outdone, Microsoft Research hints that they too have something interesting to say on this topic. I heard from a friend, and I have not had sufficient time to confirm this, that the Department of Defense wants a "computerized intelligent reader" of research that collects information automatically. Computational linguistics has had its day with its lack of diversity. It is now time to move into more significant models of knowledge structure. While I (and JJBR) agree with some of Hawkin's principles in "On Intelligence", the nature and scale of the complexity of the problem have been significantly overestimated. Since bigH made GrammarScope ATB (thanks for nothing), we're watching these developments carefully. The notion by many including, Paul Erdös and Kurt Gödel that the process of mathematics is discovery, i.e. the mathematics already exists and must be discovered, leads me to believe that the bounds of the human mind on topics of this nature are insufficient. Read "Mathematics by Experiment" by Bailey and Borwein for a taste of this approach. Find my review here. Language and linguistics and whatever name you apply to Natural Language Processing or Computational Linguistics need a big dose of this medicine. I can hear it now: More crazy talk.
Exparative modeling is a practice that originated within JJBR and receives considerable attention within JJBR. While the breadth of AI is wide and has been discredited over the years by a few inept and bumbling practitioners and critics alike, AI continues in its maturity and acceptance. I (and JJBR) prefer the term "Computational Intelligence" in this work, but still publicly use "AI", as this is still the socially acceptable nomenclature. Even computational intelligence is not effective though, as there is a significant amount of work on the distinctions and definitions of these disciplines and practices. I strive to find a better taxonomy for this work. Exparative modeling is early in the taxonomy, i.e. many things derive from the exparative approach. GP and EC, while neither well known nor well disciplined (much to the dismay of many researchers and practitioners), provide for useful models. Koza's list of Human Competitive Results here and here provide examples of successes in GP. There are many other examples in GP and EC. Unfortunately, there are difficulties in the GP. They are:
- The separation of genotype and phenotype in the classic sense in GP are blurred. It is difficult to distinguish between genotype and phenotype and it is common to bias a model if this is not clear.
- There is a lack of embriology (as distinguished from phylogeny) of the genotype.
- The evolutionary pressures of environment are not available.
- Co-evolution is non-existent.
- Lifetimes of genotype, particularly in steady-state populations, are fixed increments on generational boundaries.
- The characterization of the phylogeny of the GP is fixed.
- The brittle nature of a single fitness function.
The exparative modeling approach attempts to remedy these problems. The emphasis is still on the genetics and the phylogeny, but there is a significant separation. I'll post on these topics in the near future. Make no mistake about this viewpoint: GP is significant or I wouldn't be doing this.
I've seen the (not so) recent posts on contract-first and many of the debates on SOA (here, here, here, here and here). I have my opinions on these topics, but I'll only share the rudimentary views here. I believe in contract. I believe in policy. I believe in versioning. I think the current debate and the current (and proposed) implementations are short-sighted. In particular, I believe that there is NO distinction between contract and covenant. I think that the path we travel now, i.e. using Web Services, SOA, Indigo, BizTalk and other messaging platforms, is critical and necessary, but like any other computing platform, likely short-lived. To borrow the cliché, this is a journey, not a destination. Grab a rope and start pulling the wagon (dang metaphors). I believe that the Tenets of SO as prescribed by Box are useful and will carry the wagon for a while. But we will find significant problems in their usage over time. It is difficult to model the separation of contract definition, contract semantics and contract location (and other distinctions). Imagine the pipe that delivers cold water to your kitchen sink. This pipe is separate and distinct from the sewage pipe that is connected to your toilet. The contract is the operational semantics of the separation of the messages (water and sewage) independent of the endpoint (faucets and toilets). The pipe enforces the contract, but the contract is written and managed by the municipality in its statutes at city hall or otherwise. Contractors that construct buildings follow the contract. The pipes enforce the contract. The contract is identical regardless of the endpoint of the pipe for cold water. There is significant separation of these concepts that is woefully missing in today's messaging platforms. The insufficiencies of the four tenets of SO, i.e. tenets 1 and 2, create some NP-Complete communications problems. See this on partial and partially erroneous for the basics of what appear to be (among other issues, I'm certain) the motivations for tenets 3 and 4. Never mind what OEBs may arise. I'll have an SMC post on SOA shortly. Those that espouse BizTalk, i.e. here and here and here, as I do (I do love BizTalk), are likely well aware of the schema definition explosion that exists because of the lack of a prescriptive grammar where XSD now prevails. I believe that the pi-calculus is a great foundation, but is insufficient. I don't blame pi-calculus entirely for the insufficiencies of the messaging models in XLANG (or BPEL4WS) or BPML. The problem is that in current implementations, the semantics of XSD (there aren't any) provide no contract enforcement other than schema. Imagine an attorney, well versed in the English language with syntax, grammars and semantics, and further trained in the language of law with its vocabulary, syntax, morphology, grammar, etc. The attorney is capable of writing and defending contracts on the client's behalf. While the schema of the contract is important, i.e. the paragraphs and parts of the document, the knowledge represented in the contract is what is essential. Absent the language, the contract doesn't receive proper treatment. To improve SOA, we need language for contract and policy (and registry and other layers of the SOA). Defining schema in Tenet 3 is not sufficient. Defining policy with "semantics" in Tenet 4 is not sufficient. I'll agree that the attempt at prescriptive grammar in Tenet 4 as policy is noteworthy, but I'm going to need some mathematics, set theory, automata theory or otherwise, to demonstrate why, before I follow Indigo. Please remember here: I am motivated by the good work from the good folks at Microsoft and would like to follow and use Indigo. In the interest of brevity (oops, too late), I have a considerable amount of detail to discuss on this topic. I love this rabbit hole.
Summary
I have a lot on my mind lately and the above mentioned work doesn't include JJBR OTB stuff or my other personal interests. If you read my writings here, you know that my posts are like glue: The are usually long and require the reader spend some time discovering or understanding the concepts that I put forward, i.e. your eyes become glued to the post (or you toss it). I have verbose=on for a reason.
I challenge you today as you read this. Learn something new in some discipline other than your primary discipline. Become something better today than you were yesterday. Share that knowledge with the next person through positive and constructive means. Please by all means: hold me to a standard.
Sometime ago, linguist (and political dissident) Noam Chomsky started using the term "Partial and Partially Erroneous" (PAPE) in reference to a native speaker's grasp of the native language. When applied to language, it is a simple concept. Let's start with some of the basics.
Language is an Observable Emergent Behavior (OEB). Intelligent humans of varying levels of intelligence communicate for various reasons, the most common of which is to convey knowledge. To effect this communication, a language is used. This language may take on many forms, but we'll focus on the verbal (oral) and written forms of language. As I write this, I'm demonstrating the use of language. I'm attempting to provide you with knowledge of something that I believe to know. You are attempting to understand the knowledge that I am trying to convey (or getting bored by this). In order for this discourse (transfer through language), we must have a common understanding of the language. Here's the catch: I don't know everything about the English Language. In fact, some of the facts about the English Language that I believe to be correct (in my understanding) may actually be wrong. You also don't know everything about the English Language (if you do, please drop me a line) and it could be argued that you have (in your understanding) at least one incorrect piece of knowledge about the English Language. So how can we possibly share knowledge in the face of these difficulties?
I want to be clear about this concept. Whether I use a prescriptive or descriptive grammar for communications, I use language. I do not use XML, XSD or any other insufficient schema definition. In the language, I have lexical semantics (not axiomatic, operational or denotational), morphology, syntax, phonology and other tools at my disposal. I can communicate the knowledge that I wish to convey to another party with these tools. Again these tools are a partial set where that set may be partially erroneous.
While I'll not provide the supporting mathematics here, the problem of communications in the face of PAPE appears to be at least NP-Complete.