Here are some thoughts on domain specific languages.
There are two types of a domain specific language internal and external (see blog post).
An internal domain-specific language is a language that extends another language. One example of this is hashicorps terraform (or hashicorp configuration language). It is a configuration language that allows you to define the structure and state of a machine or groups of machines. It then takes that and transforms it into go struts and language extensions and a parser. It’s now all readable by the go compiler and converted into a runnable binary for the operating system and machine architecture.
An external domain specific language is defined outside of a language and each implementation of the parser for it is implemented in each language. An example of this is SQL. SQL is a domain specific language that allows humans to interface with the database in a machine readable but also human readable way (see wikipedia article). Every database has a different binary protocol for interacting with it but on top of that protocol is the SQL language with a little bit of difference in each database implementation. However all general-purpose languages have implemented that protocol and therefore turn that language into the protocol that the database can understand. Each language has implemented its own SQL parser that will turn it into the database specific protocol.
Internal domain specific languages are a good way to implement a domain specific language if you know that you are going to stay with that language for the duration of the project. However as technology moves on developers tend to learn new languages and not the old ones. So every generation of developers mostly learns the languages that are the best for them for whatever reason and they typically don’t learn older languages unless their work requires it. The problem is that as languages become better and innovate they leave behind code that is written in that language. If your business depends on code that is written in a language that has fallen out of fashion then your development costs will be much higher and will grow higher as time goes on unless you re-implement your business logic in a different language that new and cheap developers know, use, and understand.
The goal is to take this old language problem with high developer cost and therefore cost into account and to write business logic in an external domain-specific language that will minimize the cost of reimplementing the business logic so that a computer can understand it.
However a domain specific language for business logic doesn’t just help with migrating your business logic to keep developer costs down, it also allows you to run your business logic in various different programming languages and environments to minimize cost of network transmit to run the same logic on clients and servers to make a better experience for the end users front end and back end developers.
Now implementing a domain-specific language like this has many problems there have been many attempts to try to pull this off including jetbrains and Microsoft but I think that there is a better way to do this because this same type of thing has been done before with c and most general purpose programming languages in use today.
The problem that c fixed is that every different type of computer processor has a different architecture and therefore each of them have their own language that only it understands. What smart people did is that instead of taking the differences between the different architectures they found the similarities between the architectures and created a language that abstracted away the differences so that the programmer does not have to think about them. This problem with creating an external domain specific language seems to be very similar to the problem that c fixed. Each programming language has its own specific features they all have differences and similarities. In the example of a business logic external domain specific language, every business must write the business logic for every different language that they use that interacts with a business process. For example an e-commerce store will have many different ways to sell their products they may have a website, they may have a point of sale terminal for in-person buying, they may have an app for IOS and Android, who knows they might even have an app for a TV, they might also have an app for Windows, Mac OS, and Linux, and they also need servers to store the data and keep track of the one true data source and verifying the logic of the clients. all of these platforms have a different architecture but at the end of the day what matters to the business is that the business logic works the same regardless of what device operating system ecosystem or framework that they are built on.
This is the same principle that c was built upon and why it is the basis for the most fundamental parts of our technology today.
For actually implementing this external domain specific language taking a principle from how language compilers work today is an intermediary. A standard to connect many things on top to many things on bottom through one interface. An example of this is the llvm compiler. New languages like Swift go and rust are built on top of the llvm compiler. Instead of compiling their code down to native machine code for each platform that they are intended to run on, they compile their code down to an intermediary format called llvm that then gets converted into the machine architecture specific code for the various architectures.
Basically a standard technology that a domain specific language will be built to that will then be converted into the various general purpose languages to then be converted into a binary format for execution.
Requirements:
- The code must be open source because developers don’t want to use software they can’t fix maintain and change to their liking.
- the development of this may not be possible without a business because it has not been done before and it will take lots of resources and guidance to be able to pull off a technological change within a magnitude of c.
- at the end of the day what matters is the data of the business and so before creating an external domain-specific language for business logic we must create an API and domain specific language for specifying data and converting between different formats of data??? Is this absolutely true?
- it must be easy for developers to adopt learn and use because otherwise developers will not use it it must be better than other solutions else architects will not adopt it.
- It must also make a case for less technical people who make the business and decisions otherwise developers will not be able to use it.
- it must have hype or else other solutions that are worse will be used more
- just like c, there will be people who think that the speed of the code is the only factor that matters but that’s not the case. What matters is the cost of implementing business logic through the full life cycle: idea requirement development testing staging and production. Wind speed is a problem then the cost of implementing the functionality in a systems level language or lower should be relatively easy and planned for. However the first implementation should be getting the functionality right and be fast enough that a systems level language isn’t needed for most cases.
- it should be hard or impossible to write code that doesn’t function because of memory leaks or various other bugs.
- it should be hard or impossible to write insecure code that does what it is not supposed to do such as buffer overflows and various other vulnerabilities.
- it should be hard or impossible to write slow code unknowingly and should have minimal abstraction above the very most basic functionality.
- it should be easy to read the code that does a specific thing. ideally only needing to look at one file
- the language must allow implementations of features to be written in the underlying implementation language