A software engineer website

Prescriptivism and Descriptivism

Gautier DI FOLCO January 31, 2024 [Software engineering] #software engineering #design #haskell #functional programming #object-oriented programming

A long time ago I was watching another version of Romeu Moura's Prescriptivism vs Descriptivism.

The idea is illustrated by the point of view you can have on a "list":

Sometimes, in Haskell tutorials you have many references to Category Theory, they are often compared to Design Patterns and beginners report that they are way harder to grasp.

The thing is, whenever your define some types, you start by defining the datatype then you define the type class to characterize its property:

data AvlTree a = Node (AvlTree a) a (AvlTree a) | Leaf

instance Ord a => Semigroup (AvlTree a) where
  (<>) = mergeAndBalance

instance Monoid (AvlTree a) where
  mempty = Leaf

We can say that Category Theory is descriptive.

On another hand, when it comes to object-oriented programming, Design Patterns are the way to go.

The thing is, most of the time, they are implemented to solve a technical issue, they are implemented to be implemented.

Usually, they are named in order to reflect that:

interface IOrderFactory {
    Order startOrder(Item firstItem);

or tagged:

interface IOrderCreator {
    Order startOrder(Item firstItem);

Design Patterns in (OOP at least) are prescriptive.

Design Patterns exist in OOP to solve a lack of Higher-order constructions.

Another form of descriptive constructions are duck typing (at runtime) and structural typing (at compile time).

The duck typing in ruby:

class Glass
    def refill
      # ...

class Car
    def refill
      # ...

def gas_station(x)

You can refill your Glass in a gas station, but petrol is only good for some cars.

The structural typing in go:

type Glass struct {}
type Car struct {}

type Refillable interface {
func (g Glass) Refill() {}
func (c Car) Refill() {}

func GasStation(x Refillable) {