Lambda the Ultimate

I'll grant that other utilities will likely be superior when dealing with large search spaces. I'll also grant that logic programming is not ideal for algorithmic reasoning - and certainly not for side-effects! But these caveats you're including do much to undermine your bold claim that "prolog is by far the best, most productive, easiest programming language". To a casual observer, your argument reduces to: "prolog is best wherever prolog is best".

I'm not especially familiar with MDA or UML, but - for example - you name 'code generation' as a place where prolog is superior. By your own above caveats, you're wrong: code generation has a wide search space and a large variety of fitness functions (space and time performance, energy consumption, bandwidth expenses, latency, predictivity for real-time or embedded systems, portability, etc.). As you suggest above, some combination of generic algorithms, constraint programming, gradient descent, etc. may be superior for this task.

Anyhow, termination does 'come into it' - even without exploring search spaces. Even when just defining an ontology and applying it to reach a conclusion it isn't difficult in Prolog to muck up the order in which definitions or entailment rules are listed and end up with a non-terminating computation.

Static typing - the ability to determine when a statement or definition doesn't 'make sense' - is also of considerable utility.

Three points:

• There was a whole logic-meta programming movement a few years back at from a research group in Belgium that specialized in Smalltalk. But it hasn't seem to gone anywhere, and the meta-programs look a bit convoluted at best.
• I don't see Prolog has being very useful, but other domain-specific logic programming languages have been a bit more successful because of their limited scope (e.g., datalog).
• For me, the advantages of logic programming are obvious yet frustratingly elusive. The problem is...logic that we can encode is too inflexible and stupid, whereas humans can reasoning is the exact opposite. Until we can encode a flexible logic, I don't see much hope.

There was a whole logic-meta programming movement a few years back at from a research group in Belgium that specialized in Smalltalk. But it hasn't seem to gone anywhere, and the meta-programs look a bit convoluted at best.

Is that the right link? It is for British Columbia's research group. Did Belgium takeover Canada?

I saw the Logic AOP project, but the only paper on that sub-part of the site was printed upside down...

The only other thing I saw was Apostle, which integrates Aspect weaving into a dynamic language (Smalltalk) via incremental weaving. Unfortunately, Apostle had this funny/sad comment:

Although stable, Apostle is not suitable for real system development, but it can be played with to investigate the relevance of AOP programming in the Smalltalk world. Sadly, the source code was lost due to a laptop theft; there is an image for VisualAge for Smalltalk 5.5 image with bytecodes, available by request.

A grad student learns the importance of distributed version control and non-local backups! Doubly awesome is that person is now, six years later, interested in researching distributed VCS's from an HCI standpoint.

Also:

For me, the advantages of logic programming are obvious yet frustratingly elusive. The problem is...logic that we can encode is too inflexible and stupid, whereas humans can reasoning is the exact opposite. Until we can encode a flexible logic, I don't see much hope.

And what about using term rewriting for encoding logic? It is capable of expressing not only metaprogramming but metalogic...

That's hilarious! Thanks for pointing that out, Z-bo.

[edit]: Fortunately, if you actually print it, you can always turn the papers around. Adobe seems able to do the same.

Maybe I'll just use a mirror :)

We know how much you like reflection, but I suspect that reading in a mirror will only add to the difficulties. ^_^

what about using term rewriting for encoding logic? It is capable of expressing not only metaprogramming but metalogic...

I don't believe this will actually resolve the issues Sean faces. TRS certainly allows us to describe more complex logics and expressions, but Sean wants the ability to represent the sort of 'flexible' logics seen in humans. Humans aren't all that logical: we make illogical leaps, use analogy, view systems in many different models in parallel, and learn for better or worse by reinforcement; we imagine and predict. We also deal with deception and suspicion. Even the most rational of humans works in terms of 'justifiable' conclusions rather than the 'logical' or 'correct'.

To represent the 'flexible logic' processes seen in humans takes an inherently illogical system, but one that can integrate multiple models, multiple resources, multiple agents, multiple perspectives for any given problem. Chances are, these systems will be maintained and upgraded by different groups, will need to be plugin extensible, etc. Blackboard systems are a useful basis for such integration, but one among many. I once saw a presentation of some work by Applied Systems Intelligence (in Georgia) that described how they needed at least seven different knowledge and logic models to encode the many ways of 'thinking' and 'understanding' necessary to reach useful conclusions within time and embedded space limits... and every one of those models needed to integrate with databases.

TRS has a few sticky challenges when it comes to such integration of many different models and external resources. TRS expressions carry their whole model around with them. I suspect it could be made to work, but I'm still stuck on how to do it efficiently and effectively and in a manner users can easily grok.

TRS expressions carry their whole model around with them.

It is true that I'm unaware of what is being done here to solve this problem, but I think I need to tackle it if I want to use a Maude like language to make a case for model-driven graphics as a route towards ending the GPU API Wars. I was actually reading papers about this stuff today in the context of massively parallel rendering.

My opinion simply stated is that TRS should not be used to create Controller nodes. Haskell has this same sort of problem, but it is less evident to the untrained eye: lazy induction makes it seem like term rewriting doesn't have the Algorithms = Control + Data requirement; the compiler is still executing some sort of fancy graph algorithm. The developer still has to provide a flow of control, and that flow of control is the basis of lazy evaluation. Thus, such laziness does not transparently solve problems such as action refinement, mobility, disruption tolerance and system stabilization. -- You still have to model these problems directly so that your translation engine can 'map out' the agents correctly. Today there is way too much negotiation between the compiler and developer, and the developer always bows to the compiler's decrees. I don't have the right terminology for describing this yet, however. It is likely somebody has already thought of these issues, but my research has been an extremely wide journey across many areas of computer science, including some interesting critiques of the von Neumann model.

Your comments are consonant with my understanding.

Datalog hits a sweet spot because it doesn't stretch itself: Datalog is complicated enough to include simple domain models yet represents a relatively simple logic: it lacks negation and defaults (or priority) and any number of other complicating factors), and always terminates up to input, and always produces a single answer set. It works well with laziness - can handle both backwards and forwards chaining to fulfill the queries demanded of it. It fits very nicely into a functional programming language to operate over first-class sets or relations.

I include a variation of Datalog in my programming language at the functional strata - it's almost perfect for FRP combination of database resources (essentially, each Datalog-like expression produces a database, and may observe multiple databases). In the past, I've tried adding to my Datalog variant such concepts as negation and defaults, but in the presence of recursive implication these can produce multiple answer-sets (based on order of default, order of negation). One can reason over multiple answer sets (confer Answer Set Programming) but that's not something I'd voluntarily inflict on myself or other users. Explicit negation also allows datalog expressions to become 'inconsistent', which is non-trivial to check for in the case of distributed expression (as common in FRP). (I'm still contemplating some support for defaults with a restriction against recursion for the defaulted element.)

Anyhow, while datalog hits a sweet spot, it hardly approaches the greater depths of logic programming and the sorts of 'flexible logic' we might favor on the large scale. It has become my opinion that the major advantages of logic programming are realized in conjunction with large databases of domain knowledge and ontology. That is, both the interpretation of a logic query and the answer to a logic query may vary over time based on manipulations and refinement of both the ontology and the data resources. Maintaining these massive ontologies and data resources is non-trivial, inherently distributed, and subject to all sorts of security and market constraints. Therefore, advanced 'flexible logic' programming is infeasible without effective support for secure, distributed programming. We need build services that answer DSL-style queries via reference to amalgamations of services: databases and data distribution services, expert systems and blackboards to integrate them, search, complex event processing, etc.

Even something as simple as code production - compilation of code into another format - can leverage all the aforementioned resources and systems. Given enough knowledge of hardware resources, for example, and even of the other programs already running on the hardware, one could appropriately compile a program to take advantage of precise cache sizes, FPGAs, GPUs, properly select the right allocation and paging sizes based on HDD vs. Flash for persistent memory, etc. etc. etc. This takes a lot of data, and a lot of support from well-designed intelligent systems (which are unlikely to be hosted or maintained locally). Ah! as an aside, I was able to locate an interesting website that I haven't viewed for a few years: Declarative Meta Programming is an inspiring source of information on the subject of code generation using declarative techniques.

To achieve flexible logic programming, we must start with a programming system that offers ability to effectively compose and mash-up distributed systems. Prolog is too low-level to realize the potential of logic programming. Datalog is also far too low-level for said task, but its limited scope allows it to at least serve as a useful primitive in the development of greater systems in the same sense that simple functions or reactive objects might serve.

My own research into FRP started with an interest in how to securely and effectively integrate such high-level services. In addition to security, I wanted to make four guarantees on this integration: (1) anything you can query without side-effects, you may also subscribe, so as to minimize polling; (2) fully demand-driven from end-to-end (even across intermediate CEP systems, iterative constraint solvers, and registries*), such that sensor networks don't waste effort providing data that isn't necessary to a side-effect somewhere on the far side of the network; (3) disruption tolerance, such that if a resource goes down one can easily fallback to alternate resources or use a cached version, and such that (for SEP) if you miss a few events over brief disruption a short history can catch you up; (4) scalable multi-cast distribution of data (Akamai style). Beyond those four guarantees, distribution of the processing element to the data resource is also desirable (for performance, resilience, and disruption tolerance). Also, flexible composition of expert systems, databases, and other high-layer resources generally requires updates be separated entirely from queries. Barring a few exceptions involving fully 'reversible programming' (which is an admittedly very interesting subset), one cannot compose arbitrary external data resources if one must support 'update' semantics! FRP supports all these properties, even including decision on how to most efficiently distribute processing elements across a cloud of resources. (*: I support demand-driven properties across non-FRP systems is supported by reflecting 'demand' itself as an FRP capability emitted by every new pipe or cell. This allows proverbial forests to 'pause' whenever nobody is around to hear the trees fall.)

So can we achieve 'flexible logic' programming? I believe so. But I believe attempting to develop a "logic programming language" at the primitive layer is a mostly wasted effort. Our 'flexible logic' programming will look more like a service connection to Cyc or Wolfram Alpha, albeit with far more fine-grained distribution and many more providers due to issues of security and market. Expert systems will eventually mash up as easily as websites do today, or perhaps even more so.

I think with the above you've described Tim Berner's semantic web vision.

Any attempt to make progress on what we have today will look similar, in some respects, to Semantic Web. You should not just lump them together, though, because the differences can be significant.

I do not believe that Lee's Semantic Web - neither the technologies nor the vision - will 'succeed' (in the sense of becoming easy to use and performing well). Lee describes the SW as an extension of the current Web (and, effectively, of the current process, OS, and code-distribution model). What I describe is closer to an out and out replacement of both the current Web and OS design (even dropping DNS and Filesystems), albeit allowing adaptor components between the systems to support incremental migration. Lee describes SW as allowing widespread processing of data that is essentially held within a common 'cloud' (the 'Web') - and he basically ignores security and market issues - whereas I favor designs that carefully control which resources each element may access: no common names, but access controlled through secure capabilities and smart contracts.

You don't become a language or OS designer without accepting, at some level, that small changes in the basic elements of a design can have a significant effect upon the emergent system - its feasibility, performance, safety, security, usability, productivity, maintainability, marketability, mechanisms for composition, and so on. We don't always know what that effect will be, of course: our models are limited, especially on the human side of the equation. But many designers pursue subtly but significantly different visions and accordingly make subtle but significant tweaks in the design.

The declarative metaprogramming site you found seems to be like to what i'm describing, they talk about using prolog to generate programs in other languages

'Pure' Prolog?

I found your blog post and this ensuing reply to be very cryptic. Do you intend to follow-up this blog post with examples, or is this blog post argument the end-of-the-line?

Here is some advice.

Use 'detail sentences' more. Your points are frustrating to read because they communicate no stream of thought, but rather seem to indicate feelings and emotions. You're presenting conclusions, not a thesis or even body of discussion.

Motivate your opinion with examples in Prolog and compare to what the system would look like in a paradigm other than one limited to Horn logic. e.g. How do you do code generation in Prolog? Does backtracking or a cut operator help with the task of code generation? What is it that you are code generating? How do you verify that you are generating the right code?

Explain to me why more general logic programming (Maude) or less general logic programming (Datalog) is inferior, and why Prolog captures some mysterious sweet spot.

Perhaps explain Concurrent Prolog vs. Prolog, and motivate with a discussion of object capability systems.

Perhap explain Prolog vs. Mercurcy, and the convenience of a typing discipline that makes it easier for developers to work on larger projects.

What parts of Eclipse compete with Prolog? How do you expect the average Prolog programmer to compete with the optimized analysis-to-design translation services provided by Eclipse modeling framework's code generators? Is there a similar library for Prolog tuned by expert Prolog programmers who know a lot about spitting out efficient code?

What parts of UML compete with Prolog? Explain how you can restrict a 'profile' of modeling elements in Prolog. How do you do model checking and executable specifications? Model refactoring?

For MDA, please compare with the leading MDA vendors, such as vendors that provide translation simulators. Here is a list of MDA vendors for you to compare basic Prolog to: Bridgepoint (Mentor Graphics), PathMATE (Pathfinder Solutions), xUML (Kennedy-Carter), and Rose/RT (IBM). I would particularly recommend a comparison to Bridgepoint, as its IDE provides a full VM for model translation. How do you simulate translation from a Platform Independent Model to a Platform Specific Model? Tucked away in your post is the implicit position that Prolog is therefore suitable for real-time/engineering. Please relate your experiences in Prolog to how you've used it in real-time systems.

What ontology editing tools compete with Prolog?

What frontends to databases compete with Prolog? How does Prolog compare to Datalog? How does Prolog compare to SQL? How does Prolog compare to other query languages? Look at the Business System 12 retrospective by Hugh Darwen for a rough sketch of how one leading database researcher summarizes how one language he designed compared to a bunch of others.

For scripting langauges, please compare Prolog to bash, Perl, PowerShell and Tcl.

What about performance, such as the fact modern Prolog implementations implement multiple constraint solvers so that the end-user must be an expert in knowing which constraint solving system is suitable to their task? How does such dependencies affect the portability of Prolog?

Those are valid points, I'm making an emotional argument and so on. I'm not a programming language researcher or expert in any of those code generators/mda tools.

However, I'm coming from the point of view of a mere mortal computer user who wants to get the computer to do stuff. From this viewpoint the tools I have seen that are easieast to use are spreadsheets,relational databases, the ontology editor protege, and scripting languages perl/python/ruby/tcl. Among these, relational databases appear to me the most elegant, useful, robust and simple. Hence my choice of prolog which I think has a cleaner syntax (I'm not exactly sure what datalog is but it might be actually the language among i'm advocating but there aren't free implementations with documentation available like swi prolog as far as i can tell).

Put another way, if you consider that I as a domain expert in some activity, such as medical diagnosis or legal reasoning, want my computer to help me (without the expense of going through a programmer), I think the best choice would be a database/expert system of some kind (here is where prolog/datalog wins).

Now, what is the difference between a domain expert who is tasked with developing a medical diagnosis system (a doctor), or one who is tasked with developing a computer program (a programmer). I would argue not much. Both have large/complicated set of heuristics they would like to tell the computer (and so they should both using that same tool - relationdb/prolog).

i think there is a lot to be learned from the 80% cases. the problem is that when you get past those, things can quickly go only 1 of 2 routes: huge horrible hacks upon hacks, or unraveling it all and starting over the right way.

You might find Flora-2 interesting.

I looked at flora-2 and I think it kind of veers into a different direction. What I like about prolog/relationaldb's is the fact that everything is a table and when i go up to do something, I only have to think about joining/unifying across these flat things.

Good points, and I did not mean to deny you the proverbial seat at the table. We're all seated at the table. I am just inviting you to have me as a further listener, by requesting real world examples of how you use Prolog.

Now, what is the difference between a domain expert who is tasked with developing a medical diagnosis system (a doctor), or one who is tasked with developing a computer program (a programmer).

The difference, since the 1990s (and perhaps earlier), has been that there are no longer "Programmer/Analyst" job positions. This job title is effectively extinct today, because there is much greater emphasis on having both a domain expert and a programmer. We might even separate this further by inserting in a "product manager": somebody who can talk to each in their own native language. For a medical diagnosis system, I've never heard of a doctor also being the programmer... Instead, the domain experts are used to validate the accuracy of the expert system (to ensure things like blood disease diagnosis is not incorrect, and that the patient does not receive the wrong medication).

Put another way, if you consider that I as a domain expert in some activity, such as medical diagnosis or legal reasoning, want my computer to help me (without the expense of going through a programmer), I think the best choice would be a database/expert system of some kind (here is where prolog/datalog wins).

I'm not certain judicial reasoning and proof lends itself well to Prolog. I am only aware of two full-length books on the subject, neither of which I have read: Judicial Applications of Artificial Intelligence and The Dynamics of Judicial Proof: Computation, Logic, and Common Sense. It seems like except for DOCU-PLANNER, custom systems were built to support legal reasoning. I'm also aware of Peter Tillers' website dedicated to MarshallPlan which is, as far as I know, the first software program to allow users to do heuristic analysis of very large amounts of evidence. I mainly was interested in this because J Storrs Hall mentioned the application of artificial intelligence to judicial reasoning in his book Beyond AI, but did not provide any references. My curiosity stopped when I confirmed it was true, and so don't expect me to be especially knowledgeable here :) I am just attempting to understand your point.

dmbarbour mentioned above the site declarative metaprogamming http://soft.vub.ac.be/DMP/ and they happened to choose prolog for doing their metaprogramming so there must something to it.

"The difference, since the 1990s (and perhaps earlier), has been that there are no longer "Programmer/Analyst" job positions. This job title is effectively extinct today, because there is much greater emphasis on having both a domain expert and a programmer."
If that is indeed true, then I regard that as more of a failing of the software tool industry/academia than a success (perhaps they're not emphasizing enough how good and easy to use relationaldb/prolog is!). Why hasn't programming become another basic literacy just reading,writing,arithmetic (see Alan Kay) that professionals use as part of their everyday work.

Modern analysts with computer skills use modeling software and tend to focus on principles of stable design, such as: (1) set-based classification of real world entities into things called "Classes" (2) model-driven engineering, where the compiler does the bulk of the "programmer" work. Relational theory is as important as ever, since good model checking software depends on analysts who understand third normal form.

Some punditry: I think it is important to realize in programming language theory that much of the important math will eventually be resolved (just look at the advancements at the POPL and PLDI conferences each year), and the main issues that remain will be portability of models and ensuring that sharing a model (and therefore porting it to the next person's computer specifications) maintains or improves its nonfunctional characteristics. At the same time, we're seeing fewer and fewer interesting papers from conferences like OOPSLA, and now that OOPSLA is re-branding itself as SPLASH, the writing is on the wall for the classical notion of "programmer". (The Visual Studio team already hires C.S. M.Sc. graduates to be product testers, foreshadowing the day when IDE's will be built solely by team's of Ph.D.'s) What's especially telling is that, a few years ago at OOPSLA, there was a birds-of-a-feather discussion to talk about how to handle the multicore kerfluffle, led by Brian Goetz. According to Goetz's report of that BoaF, nobody had any clue how to help the average programmer write parallel programs. Yet hardware folks have been working on personal supercomputing since the early '60s (led by Gerald Estrin), and there was even a 7 year research project into parallelism in the '80s about how to apply massively parallel techniques to systems theory (including exotic prototype concepts such as neural network-driven compiler optimizations [which have unique advantages traditional pipelined compilers do not]). Likewise, things like Lamport clocks, that require distributing the clock to all components in the system or coming up with schemes to avoid distributing a clock, are being reconsidered in favor of clockless and concurrent designs (e.g. asynchronous circuit designs).

"Modern analysts with computer skills use modeling software and tend to focus on principles of stable design, such as: (1) set-based classification of real world entities into things called "Classes" (2) model-driven engineering, where the compiler does the bulk of the "programmer" work. Relational theory is as important as ever, since good model checking software depends on analysts who understand third normal form."

I always thought that object-orientation (classes) and relational were on opposing teams (object/relational mismatch), and I always thought the object folks were just plain wrong. If you look at the results, most useful (commercially used) software is essentially a relational data model and queries (with stuff on the end like scripting languages to prettify the result). I kind of disregard operating systems/databases/browsers because they haven't produced anything noticeably improved since their first incarnations in the early 70s/90s (the man hours have translated into not all that much - maybe because of their use of c/c++ and object orientation).

I always thought that object-orientation (classes) and relational were on opposing teams (object/relational mismatch), and I always thought the object folks were just plain wrong.

Object-oriented languages with "classes" are not necessarily model-driven engineering "classes". Model "classes" are really just a set-based classification scheme; object-oriented programming languages confuse this with concepts such as "implementation inheritance" and procedural method resolution that allows a subtype to delegate implementation concerns to a supertype, in turn conflating the notions of type and class. Likewise, issues such as collaboration are not addressed by set partitioning, but rather by collaboration schemas (typically expressed via a collaboration diagram); object-oriented programming languages instead achieve collaboration via block-structured procedural message passing, which makes things like clockless, concurent, asynchronous, distributed implementation awkward and error-prone and why model-driven compilers implement this for you. Likewise, due to the linear store of the von Neumann model, many object-oriented programming languages distinguish between composition and aggregation (which is a slippery slope that must immediately address new problems such as ownership of the resource and resource lifecycles). In fact, the first version of UML distinguishes between composition and aggregation as well, principally to allow reverse engineering source code written in object-oriented programming languages like C++ (improving the accuracy of model extraction). Fortunately, UML 2, with MDA Profiles, has cleaned all of this up. Unfortunately, UML now looks beyond bloated to the untrained eye and it takes a real expert to understand all the layers and surface volume. Also, object-oriented programming languages tended to encourage ambient authority (e.g. C++ "friend" construct), which is antithetical to object-oriented modeling, since objects themselves are the simplest and most uniform construct for building secure distributed systems; object-oriented programming language elements like "static" and "import" thus interfere with truly object-oriented principles like having a nonlinear word-datum limit*. As a consequence, the theory of naming in most object-oriented programs violates encapsulation of the "objects" in these languages, in the sense that these languages do not provide extreme hiding and protection of state-process, because you should only be able to invoke an object you can name, and the object should only respond if you have the authority to ask it to do something.

I attribute the misunderstanding between classes and types to Liskov's Substitution Principle paper, which many accidentally mistook as an axiom of object-orientation rather than a derived lemma. For example, Lieberherr's Adaptive Object-Oriented Software programming paradigm, based on the principles of adaptive grammars, actually has little to do with developing real-time object-oriented embedded systems. Lieberherr qualified his use of the "object-oriented" buzzword in part by stating his system allowed preservation of the Liskov Substitition Principle, yet this was only true in a very twisted sense. (This is not meant to disparage Lieberherr, as many of his ideas, such as combining dictionaries and dependency propagation graphs, have ended up being re-invented by Inversion of Control/Dependency Injection libraries such as .NET examples NInject, Autofac and StructureMap in the form of buzzwords like "Profiles", "Autowiring", and "Contextual Binding"; in doing so these IoC libraries scrap the Demeter project's useful visualization language, powerful asset querying language, and convenient syntactic DSL. On the other hand, the key improvement made by these IoC/DI libraries is runtime containment for provisioning resources to subsystems, which allows hotswapping at the expense of not being able to directly reason about the effects of hotswapping on things like caching. Hotswapping turned out to be such a popular feature, due to the startup time of many large applications, that the weaknesses have so far been almost totally ignored, to the point that many engineers conflate hotswapping with run-time modularity.)

Also, the importance of third normal form in modeling is independent of implementation. Not putting knowledge responsibilities into normal form will necessarily lead to unnecessary guards, and in any complex system, guards hidden behind interfaces will be the cause of architectural decay as it explodes the state-process based on individual elements' peculiarities rather than sets of elements. No mathematical discipline is interested in studying individual elements on an ad-hoc basis, and object-oriented modeling is not an exception.

The major problem of OOPSLA research in the '80s and early '90s was that things were happening so fast that few researchers were closely examining implications. They made overpromising claims rather than trying to distill the nature of good software. Some of the brightest minds, like Henry Lieberman, published only a paper at OOPSLA and retreated back into their academic strongholds (Lieberman has always been profoundly influenced by MIT's AI culture).

^{* To the best of my knowledge, the thorough benefits of a nonlinear word-datum limit were first enumerated by JK Iliffe in his Basic Machine, a theoretical machine described in his book Basic Machine Principles. However, I have been searching for earlier prior art - tagged architectures existed before then, but a thorough treatment of how they compared to linear store architectures is hard to find.}

Well most of that went way above my head so I can't refute it, but I will say, when you said "Unfortunately, UML now looks beyond bloated to the untrained eye and it takes a real expert to understand all the layers and surface volume.", it seems to me that something is wrong with the industry. If the point of higher level languages is to make programming easier than assembly, well, this is like going back to assembly.
Also, regardless of what the exact meaning of uml is, whether it's object oriented in the sense of OO languages or not, I still think the relational db level abstraction is better than uml. I know of at least one 'non-programmer' (a managerial accountant) who writes sql queries as part of his job.
When you wrote "Not putting knowledge responsibilities into normal form will necessarily lead to unnecessary guards, and in any complex system, guards hidden behind interfaces will be the cause of architectural decay as it explodes the state-process based on individual elements' peculiarities rather than sets of elements.", I'm not exactly sure what you mean, but it sems like you agree that relational model is better as well.

Also, the importance of third normal form in modeling is independent of implementation. Not putting knowledge responsibilities into normal form will necessarily lead to unnecessary guards

Can you recommend a book or article about this? I never heard about this before.

Executable UML: How to build class models by Leon Starr. However, don't expect Leon to approach the subject by directly explaining normalization. Leon's position is that if you simply look at the problem domain and start to uncover entities and think of responsibilities for those entities and how other entities might interact with that entity, then you'll typically arrive at third normal form. He gives a couple examples, such as modeling graphics applications that manipulate rectangular graphics.

Towards Executable UML - Code Generation From Interaction And State Chart Diagrams by Martin Marinschek, Ph.D. dissertation:

When designing xUML classes, their attributes and
identifiers, the relational principle of the first normal form, second normal form and third normal form should be obeyed – making the close coupling between xUML and relational principle even more obvious. An introductory explanation of these concepts can be found in [=>Normalization], and in [Sta02, p. 61ff] they are applied to xUML; although not explicitly mentioned.

[Sta02] is referring to Starr's book. Executable UML (xUML) mainly derives from the Schlaer-Mellor methodology of "modeling the world in states" and "modeling the world in data".

Also, H.S. Lahman, one of the best modelers I've ever seen, routinely mentions 3NF on usenet://comp.object (e.g. RE: How to Introduce OO to Structured-Method IT Person?) and has a blog post dedicated to the role of normalization in the modeling process. As H.S. Lahman points out, normalization critiques of OO systems are rare, because a poor design is usually the result of not doing abstraction based on a problem domain, but rather the data coming to the messages (instead of the messages coming to the data).

A separate philosophical question is whether this is The Right Way to think about systems theory. As I've already mentioned, adaptive grammars argue otherwise, but adaptive grammars also have not been used in systems theory (that I am aware of... perhaps someone like John Shutt could point us to something, though, as he is quite knowledgable on the topic of adaptive grammars) and so the full implications of adaptive grammars applied to very large scale systems has not been adequately explored (IMHO).

As an aside, more modern object-oriented programming languages, like Scala, have added support for dealing with temporal consistency via incorporating traits into the type system; traits are the most natural way I know of to encode a GoF State Pattern into a textual programming language, but the downside is that you have to encode actors to asynchronously transitition from one Role trait to the next. So it is pretty evident that textual programming languages and system modeling theory will eventually converge.

That project doesn't necessarily use Prolog, through and through.

Sofie Goderis, for example, is a Ph.D. student whose work I try to follow. She has published articles in the Journal of Object Technology, such as: DEUCE : A Declarative Framework for Extricating User Interface Concerns. I really like her stuff, and here is one great quote from the aforementioned article:

Existing UI approaches, including the ones based on the Model-View-Controller (MVC) architecture [23, 17], support a limited form of separation of concerns (see also section 7). More precisely such approaches focus on separating UI visualisation (in a view) from the business and data logic (in a model), and neglect the extrication of UI behaviour. As a result, evolving the UI's behaviour still requires browsing the source code, manually adding new UI behaviour and subsequently connecting it to the business logic where appropriate. In addition the code handling for the contextsensitive nature of the UI needs to be scattered throughout the application as well. This is why we advocate a built-in solution that covers the separation of all concerns in an integrated manner.

Like Sofie I am personally also interested in using constraint programming for user interfaces. However, I do not quite believe that declarative meta programming as practiced in DEUCE is the right way forward. Lately, my interest in GUIs has led me to recommendations by Allan McInnes and Charles Stewart to look into Hyperedge Replacement Grammars (thanks Allan) and Constraint Multiset Grammars (thanks Charles). Constraint Multiset Grammars already have novel applications to graphics applications in the area of pen descriptions; I am still wraping my mind around HRGs so I don't know if they're useful or not.

As a comparison, Sophie uses SOUL and the Cassowary constraint solver as the basis for DEUCE. Leo Meyerovich and I recently had a discussion about Cassowary on LtU. See: Computational complexity of cascading stylesheets?

By 'pure' prolog I mean the logic and procedural features of prolog, - (remove the recursion/lists/map etc.)

I must be missing something. How is induction not part of logic? And how is recursion not procedural?