As custom language injection working with concepts from wiki

Would it be possible to make this plugin handle the markdown language extension from Intellij and use the concepts from wiki?

This may sound obscure - hope this image starts clarifying but please advise how I can explain better.

[vsch]

@SemanticBeeng, the idea of keeping application code in sync with concepts from business domain is a great theoretical goal but impossible to realize in practice because code and business ideas are communicated in completely different languages and deal with different levels of abstraction. There is an irreconcilable impedance mismatch.

It has been a great sell to business heads for decades who have been eager to eliminate the quirky, expensive programmers out of their hair. Unfortunately, most of these business people have no clue to what an implementable specification would look like or how much effort it would take to create. Much of the quirkiness of developers comes from trying to clarify and disambiguate the business domain provided marketing glossy they think is a specification.

The two domains think at different levels of abstraction, as they should. They address different problems and exist in different environments.

It is similarly hard for most programmers/developers to understand or care for business issues. Not their interest. If it was, they would be doing business not software development.

All adding business rules to code will do, IMHO, is add irrelevant noise to code which is already complex and cluttered enough without it.

Another problems is by the time business rules are made clear and precise enough to make sense in a programming environment, you will have created at least pseudo code. Except it is untested nor verified, business people won’t understand it and neither will the programmers because it will be “Esperanto” of programming which no one cares to learn.

I have seen many, many attempts at this over the decades and no one came even close to making something worth learning much less making it central to their mission critical projects. In the end it is easier, faster and cheaper to keep the two worlds separate.

I also don’t see why the great hype for better documentation when hardly anyone bothers to read it once it is created. What they really want is a quick reference from which they can extract the needed information in minimal time and get on with their work.

I don’t put value in comments, much less other documentation because I do not trust it to represent what the code really does. I prefer to read the code since this is what is executed, not the comments or the docs.

For me, even javadocs are a waste of time except in stable, reusable code. If the code is in development or rapidly evolving, comments tend to take more time to maintain and keep in sync than the value they provide. Especially when they get out of sync with the code and are nothing but misdirection.

[SemanticBeeng]

I also don’t see why the great hype for better documentation …

My point as not about “documentation” but about “design”. But even about “documentation” this is not correct: best code bases have kickass documentation and we really depend on it. See Akka for example but there are many.

Sure, close this. The response has good points about coding but understated the premise of my ask: literate programming, Domain Driven Design, (ubiquitous language), design process in code, etc.

In the overall SDLC we work with at least three domains:

• business domain (including here requirements also) : what and why
• design domain - how
• technical domain (frameworks. general programming languages, etc) - what pieces to leverage

Unless these three are not weaved together harmoniously across the team and time we get the regular code: cryptic, non-reusable, to be re-written. Anyway, we agreed to disagree.

For others that relate to my points: have since been looking at laika: functional library in Scala

• https://planet42.github.io/Laika/01-about-laika/01-features.html
• https://planet42.github.io/Laika/03-preparing-content/01-directory-structure.html
• https://planet42.github.io/Laika/05-extending-laika/03-implementing-directives.html