Thanks for clarifications! Two points I forgot to mention regarding ontologies and “all things semantic”.

Yes, expressive power of DLs are deliberately set to have decidability (and avoid halting problem). So, yes, of course, ontologies can’t replace software, but it’s not the point.

For example, regular expressions are useful though the language they recognize is quite limited. (Sorry, for me it’s a bit easier to talk about expressiveness in terms of Chomsky language hierarchies here.) This is actually a very compressed cousin of UML state machine, equivalent to FSA (finite state automaton), etc. Mini-language.

Basically, ontology (and instances, which are created according to ontology — I mostly familiar with RDF/OWL way) is an approach to store data in a semantically exact way. It has a lot of good properties, one of which is that eg RDF graph is just “a lake”: New facts can be just added, not fuss with foreign keys, schemas, whatever. And all that is possible only because we agree on semantics of specific terms. I am sure, you are not against data structures and databases, so we most probably do have no disagreement here.

The question is: How to add Turing-completeness to ontology to make it work? That is where rules come into picture. So with semantic web tech the performative/expressive dichotomy is even clearer: rules are about performance, knowledge bases/ontologies (ontologies plus instances of facts) are exactly that, in my opinion. Only there is no code, only rules and inference engine(s), which are generic. There are ways to encode rules in same way as facts. So basically the end result is the same as with text in programming language. Certainly, it’s overkill to program clothing store on a platform like http://callimachusproject.org/ , but my point is: if you build Enterprise-grade systems, the flexibility there necessarily adds layers of indirection/abstraction. Having rules in the form of interpretable data instead of lower-grade data (code source) becomes a must. (here actually comes UML. There are round-trip tools for UML to be turned into Java and even back. I personally doubt they are of any value, but the idea of those was to “make it easier”… maybe due to Java is not quite convenient as is, too verbose at least)

As we are mostly interested in the domain model, everything else just supportive / auxiliary, the “language” used for domain model matters. And that language is not necessarily programming language. It can be some higher-level, domain-specific beast. And this means that we can design most interesting parts of software with higher level languages than even Python. Provided our domain is narrow enough. Do you have any argument against that?

I am not sure myself whether the above is ignoratio elenchi, but I feel like making Python or C++ source code the only source of “architecture” and design media an oversimplification. Higher level views and languages can be there as well. The only valid point I see why we should create documents, which are manually connected to the resulting software design. But there are many ways for “automated” connect: For example, I mentioned (in my comment to one of your articles) acceptance tests can be written in a nearly natural language, rules+ontology approach above provide higher-level representation, even UML (with round-trip) can be thought of such a tool (so I doubt it is more convenient than plain code), you can use Attempto Controlled English or even natural-language programming / automatic programming techniques (they will probably even work for narrow enough domains). Oh yes, object-oriented code decomposition can also be roughly understood as ontology+rules (class inheritance is IS-A, composition HAS-A, and then also USES-A, and other semantic relations).

All that said, we need to (continuously in iterative development case) bridge the gap between engineers and non-techies.

I somehow missed Robert Brandom’s books. Seems now, that I need to read some as I guess your reasoning is based a lot on that, and your views provided a new perspective (at least to me).