Declarative Programming

1) Configuration versus convention

From https://golang.org/doc/articles/go_command.html

The way to achieve the simplicity of a configuration-free system is to establish conventions. The system works only to the extent that those conventions are followed. When we first launched Go, many people published packages that had to be installed in certain places, under certain names, using certain build tools, in order to be used. That’s understandable: that’s the way it works in most other languages. Over the last few years we consistently reminded people about the goinstall command (now replaced by go get) and its conventions: first, that the import path is derived in a known way from the URL of the source code; second, that the place to store the sources in the local file system is derived in a known way from the import path; third, that each directory in a source tree corresponds to a single package; and fourth, that the package is built using only information in the source code. Today, the vast majority of packages follow these conventions. The Go ecosystem is simpler and more powerful as a result.

We received many requests to allow a makefile in a package directory to provide just a little extra configuration beyond what’s in the source code. But that would have introduced new rules. Because we did not accede to such requests, we were able to write the go command and eliminate our use of make or any other build system.

It is important to understand that the go command is not a general build tool. It cannot be configured and it does not attempt to build anything but Go packages. These are important simplifying assumptions: they simplify not only the implementation but also, more important, the use of the tool itself.

Another example:

Hapi configuration-based server framework

When you make the reverse (convention over configuration), you can see why Ruby on Rails sucks.

2) Infrastructure as data

You can write Ansible modules in any language as long as it outputs JSON data

3) Event Emitter pattern

The Event Emitter pattern in Node spawns a Go version in https://github.com/chuckpreslar/emission

4) Continuum policy-driven product

Apcera’s Continuum lets you declare policies from the get go

5) Dockerfile

Docker lets you build images through a text file called Dockerfile

6) Configuration files

Windows .ini, MySQL .cnf etc

7) Environment variables

Exist in Windows and Linux

8) Static HTML files

This is the key to separating presentation layer from business logic layer. When you make static HTML files, your Web server application essentially becomes a RESTful API server

9) Promise-based programming

Like Event Emitter in Node, promises let you separate data from functions.

10) Separate data from functions

This is the essence of declarative programming. It is the reason why OOP sucks (just ask Joe Armstrong – http://harmful.cat-v.org/software/OO_programming/why_oo_sucks)

Advertisements

Subjectivity aside, leave a reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s