There is a common thread throughout this site (although some of the content pre-dates this thinking) which is that concise languages (domain specific languages) should be used to describe business logic, processes, business aims and architectural solutions. Pictures are great to communicate high-level concepts but detailed thinking needs an exact textual description - we do not use flow charts to design programs, not in the last 30 years anyway.
The Domain Specific Language (DSL) section of this site explores different languages and uses - but a key concept is that they will have a common metaphor / style and will be modular - will allow a new language to be build using pre-built DSL sub-languages.
Moreover the common compute technology (a common bytecode interpretor) will also support some of the more detailed system architecture - a common compute machine will support distributed computing, for example supporting thin clients and distributed BPM processing.
To achieve this we need to define a superset language - if you like a grand unified language which will show what the common syntax will look like. This will provide the ground rules for the different DSL languages we will define and implement - it will provide the common syntax metaphor that will allow developers to feel that the DSL have a common heritage. It will also allow us to define the superset bytecode and assembler language needed for the runtime.
This language is called CoreLang.
Will CoreLang ever be implemented? I believe the answer is yes in time ... but subset specific DSLs will be implemented first, each a step in the overall CoreLang implementation.
So the key initial CoreLang deliverable are:
- The overall language syntax and draft reference
- The CoreLang parser
- The draft bytecode (CLBC) and assembler (CLAL) definition and implementation.
This will provide a firm foundation for early developments of our DSL languages and distributed compute capability.