Value-Oriented Programming (matt.diephouse.com)

Thank you for the explanation!

If someone such as myself wanted to understand the philosophy of functional languages, do you have any book you'd recommend? Learning the languages is easy enough, but if I ever tried them I'd want to do it using the ideals of functional programming vs. trying to contort the language to be something it isnt't.

I'm noticing a trend more and more where developers move to FP over OOP after a decade or so in their career. I feel if I don't give it a look, I could be missing an obvious lesson.

More importantly, this forces you to create an explicit interface for any code you'd like to reuse between implementations.

Inheritance is fragile for a lot of reasons (see e.g., fragile base class). But the most common failure modes all have the same thing in common: the error happens because a developer fails to realize that there's an implicit interface between two things in the object heirarchy.

What is the difference between subtyping and subclassing? It looks confusing to me.

"Typical OO languages" meaning statically typed? I've struggled with all the problems discussed here in C++ and C# but not in Python or Ruby.

Equivalent, but not exactly the same, mostly in the sense that Java is less dynamic than Swift. Ones I know of:

- In Java, you have to declare the interfaces that a class implements when you declare the class. In Swift, you can add conformance of a class to a protocol, even if you don’t have access to the class’s source code.

- In Swift, protocol definitions can contain implementations of methods (I think this is being or has already been added to Java recently). For example, a method foo that takes a string argument could call the foo overload taking a character for each character in the string. That way, classes conforming to the protocol need not define the method taking a string.

- Even if the protocol definition doesn’t declare that default implementation, you can add one by writing an extension method.

All of those are useful, but also can make it hard to understand what code exactly is being called.

(More info at https://docs.swift.org/swift-book/LanguageGuide/Protocols.ht...)

> "protocol" seems to be the older name (per one of the guys that wrote Java)

Quite likelym as another Guy (Steele) responsible for Java was also a big name in the Lisp world, including chairing the committee that wrote ANSI standard for Common Lisp. In the Lisp world, protocols were a known concept. In CL nomenclature, a protocol is a set of generic functions and types used by those functions. Which is kind of like a Java interfaces, except with multiple dispach based on any of the arguments instead of the typical single dispatch of Java and friends.

For example from TFA, a CL protocol would be a #'draw generic function and a 'drawable and 'renderer abstract types. The particular #'draw methods could be specialized on either argument (or both), and we could also imagine another protocol consisting of (the same) renderer type and some geometry-related generic functions.

Point being, protocols are both an old and very useful concept, and like usual, C++/Java-like languages only allow expressing a small subset of it.

Delegation is extremely powerful, but it is easily implementable in most OO and Functional languages, no?

Kotlin and Groovy are two languages where you get direct support for delegation.

What do you mean by delegation?

Swift specifically took these ideas from Haskell, Haskell was even mentioned in comments in Swift source code for a time.

I don't know how Haskell does it, but, at present, Swift enums with payloads have caveats that simple Swift enums don't:

- they use this verbose syntax to access payloads "if case let .foo(bar) = baz { /* do something with bar */ }" The alternative being to do everything in a switch statement, and possibly create a local variable thanks to scope

- their payloads are not convertible to tuples, despite their cosmetic similarity

- they do not allow default values, despite their cosmetic similarity to swift function parameters (which do support default values)

- they aren't automatically Hashable and Equatable

- they aren't automatically included in the Enum's array of ".allCases"

The great thing about Swift is that all of these issues can be worked around using extensions. Unfortunately (the way I do things, anyways) that means a lot of the time in Swift, the Enum itself is maybe 5 lines long, while my extensions to work around the above limitations go on and on for another 30+ lines.

You're right, I was thinking of something else.

The first part of the article (which summarizes a WWDC talk on protocols) presents something you can do with interfaces and structs in Go. But in the second part, where the author presents a superior pattern based on values and sum types, is precisely something you can't currently do in Go.

To do what he proposes, you need sum types akin to what Rust calls enums. In Rust it would be something like:

  enum Path {
    Arc {
      center: CGPoint;
      radius: CGPoint;
      start_angle: CGFloat;
      end_angle: CGFloat;
    },
    Line {
      start: CGPoint;
      end: CGPoint;
    }
  }

The idea is that you have a value declared as Path, you can only assign Arc and Line to it. Similarly, if you want use a value, you have to match against it:

  match value {
    Path::Arc => ...,
    Path::Line => ...,
  }

or you can destructure:

  match value {
    ...,
    Path::Line { start, end } => {
      draw_line(start, end);
    },
  }

Languages that have sum types are usually expression-based, so the compiler insists that your match is exhaustive, or it won't compile:

  // Fails with compilation error
  match value {
    Path::Arc => ...,
  }

  // This works
  match value {
    Path::Arc => { println!("is an arc"); },
    _ => { println("is something else"); },
  }

The closest Go has, as I said in my comment, is the ability to unify multiple structs with a dummy interface, e.g.:

  type Path interface {
    isPath()
  }

  type Arc struct {
    center, radius CGPoint
    startAngle, endAngle CGFloat
  }
  func (Arc) isPath()

  // etc.

Now you can do a type switch:

  switch t := path.(type) {
    case Arc:
      ...
    case Line:
      ...
  }

However, since Go's interfaces are implicit, it doesn't know that Arc and Line fulfill a possible union of types, and so the switch cannot fail if it's not exhaustive:

  // This compiles
  switch t := path.(type) {
    case Arc:
      ...
  }

I'd love to have sum types in Go; it feels like a fairly natural fit for the language since we already have high-level constructs like interfaces:

  type Path enum (
    Arc {     
      center, radius CGPoint
      startAngle, endAngle CGFloat
    }
    Line {
      start, end CGPoint
    }
  )

The syntax for matching could be exactly the same as today, even. It would be to cool to be able match with destructuring, but given that Go doesn't support any destructuring today, I'm OK with this being left out to keep the language small.

As an aside, it's important to note that in Rust, enums aren't just structs; they can be tuples, too, or constant values:

  enum State {
    Alive,
    Dead,
  }

Here, a value of type State can be either Alive or Dead:

  let s1: State = Alive;
  let s2: State = Dead;

And you can pattern match against it. The closest Go has to this is numeric constants with help from the iota keyword:

  type State int
  const (
    Alive State = iota
    Dead
  )

But yet again, this is a hack that doesn't provide much type-system safety:

  var s State = 123  // Invalid, but compiles