The art of declarative programming

The usage of declarative programming has been rather popular these years. We could see a lot of products/solutions that are big fans of declarative programming. A typical declarative programming example is Kubernetes YAML, where users only need to define what he wants instead of how he wants it to be done. Indeed, the model is closer to the real world than imperative programming. Let's image a customer went into a restaurant, he would tell the waiter he wanted a Pizza or a steak instead of telling him how he wanted them to be cooked.

Essentially, declarative programming is just the configuration split from code. And YAML became a very good choice because of its easy humans readability. With declarative programming, IT engineers' work is simplified and work efficiency can be tremendously improved, because the imperative part has been detached from it. That said it gives us an opportunity to survive with playing with the configuration, rather than messing up with the code. To put it even more simpler, it's about how and what. The program takes care of how and we human beings take care of what. It's an architectural style or a design pattern which has been widely adapted by many tools. In respect to delivery, the declarative programming part can be handled by operational engineers without struggling on knowing "how" the tool does the work. From the user's perspective, the declarative programming part is a format of user interface. It's just unlike a Web user interface which has human friendly intuitive buttons and forms. In that regards, a program which has split configuration from logic forms a basic interactive tool. It's a basic form of a product.

Now let's briefly have a look at a few examples. For example, speaking about Kuberntes Operator, let's say we use Golang to implement an operator. We implement "how" with Golang structs and functions via complicated logic, then we define Custom Resource Definition (CRD) in YAML to express "what" the logic wants. Similarly, the terraform custom provider comes with the same philosophy, where the HCL expresses "what" the Golang program logic wants. And the Golang program basically defines "how" to calculate the differences between system status and our desired status(HCL). However, if we trace back a little bit more history, declarative programing is not something new, almost every configuration management tool such as Ansible, Puppet, Chef etc, has implemented that philosophy. You can go deeper by writing a custom Ansible module or a Puppet defined type.

Having written the above, we can see declarative programming makes our work easier, but it doesn't mean imperative programing is disappearing. Actually, these two capabilities form a very hot job type in the market. And it's called Devops. A devops develops the "how" logic and operates the system by defining "what" an organization wants. These two actions map respectively to development and operational skill. In my opinion these two skills are both quite important. With development skill, you can create or tailor a new tool and with operational skill you can make the best use of a tool without reinventing a wheel and also provide suggestions on user experience. A tool with poor user experience is always a bad tool and would have no market. So if you want to be a real programming artist, both declarative and imperative programming matter.