The bigger the interface, the weaker the abstraction

https://functionallyimperative.com/p/the-bigger-the-interface-the-weaker

by zdw • 3 years ago

97 59 3 years ago

ilrwbwrkhv• 3 years ago

Go indeed has a simplicity and elegance that makes it really easy to write code which is highly performant and easy to maintain. That is the only reason I picked go when moving from common lisp.

moffkalast• 3 years ago

from common lisp

Is there such a thing as uncommon or rare lisp?

umanwizard• 3 years ago

Common Lisp is the name of a programming language.

yellowapple• 3 years ago

Possibly even Epic Lisp, Legendary Lisp, or Exotic Lisp.

kazinator• 3 years ago

Yes. In the long history of the Lisp family of languages, many dialects have been created, and most of them are uncommon and rare, becoming more if they are disused and recede into history.

jonahx9• 3 years ago

Slightly OT: I like Go, but the "-er" convention, while useful, has always bothered me because of the following inconsistency, well illustrated by two examples from the article:

    Writers write.
    Readers read.

    type Reader interface {
     Read(p []byte) (n int, err error)
    }

    type Writer interface {
     Write(p []byte) (n int, err error)
    }

In a Go interface, a reader doesn't read: a reader gets read from. The reader (in the English language sense) is the client code of the Reader interface (in the Go sense).

That said, I find the Java "-able" convention even uglier, though it answers my complaint.

tareqak• 3 years ago

Why not use both? -er’s do stuff to things while -able’s get stuff done to them and use them as it make sense.

Use the one that makes the most sense given the situation.

jonahx9• 3 years ago

You could, but this is not Go's convention. Go's convention is that when you have an interface with a single method "x", you name the interface "xer".

This has the advantage of being simple and mnemonic. It has the downside I already mentioned.

taeric7• 3 years ago

Works if you consider the reader is what you use to do the reading. You have a source you want to read, so you get a reader that can do that.

Literally, you get a reader when you want to read something. You get a writer when you want to write something.

Though, beware thinking you can solve this with word choice.

jonahx9• 3 years ago

Works if you consider the reader is what you use to do the reading. You have a source you want to read, so you get a reader that can do that.

This strains ordinary language imo:

Say you have a "log" which implements the Reader interface. When I call "log.read()" surely we are reading from the log, no? The log itself isn't the reader. This matches everyday usage.

Perhaps your argument is that you can envisage the "log" object as an abstract "reader" of the bytes on disk, or something like that -- so the mental model is not a "log being read from" but instead "bytes on disk, an object able to read them (the Reader), and the code using that object to do the reading". In this worldview one never does anything oneself, but always uses a tool to do that thing -- the "-er" tool. I dislike this as it introduces an unnecessary layer of abstraction, but I grant it resolves the issue consistently.

Also in this conception now I have a variable named "log" which does not represent the log but "a reader of the log". So you have to either ignore that inconsistency or name the variable "logReader", which introduces extra verboseness everywhere.

The other resolution is simply to say this is a programming language, not ordinary language, and we decided that having a consistent, mnemonic way to name one method interfaces was more important than respecting natural language analogies. So f it, we're using "-er" to mean "-able".

I would be curious to know what the actual conversation was during the development of Go.

jiggawatts• 3 years ago

A diagram that made things click for me is putting different abstractions on a grid showing the different combinations of high level contracts they fulfil.

Every combination of push/pull, read/write, and sync/async can exist and makes sense.

The Go interface is “sync pull read” which is “Readable”.

Then “Reader” is “sync push read”, etc…

Another axis is “single item”, “sequence of items”, or “contiguous array chunks of items”. These are “property”, “iterator”, and “stream” respectively of synchronous. They’re “task”, “asynchronous iterator”, and “async stream” if non-blocking. Etc…

paulddraper2• 3 years ago

The Reader is doing the reading.

  reader.Read(p); // reader, please read into this array

The caller is obtaining the result of the read operation.

---

What mows a lawn? A person, or machinery?

In English, either can be referred to as a "lawn mover." However, most often "lawn mower" has the most direct meaning: the machine.

jonahx9• 3 years ago

See my reply here for the problems with that: https://news.ycombinator.com/item?id=36926392

EDIT:

To elaborate my reply there tailored to your lawn mower example...

What mows a lawn? A person, or machinery?

Yes, in this case the tool analogy matches real life (and your interpretation of Go interfaces as tools): I use a lawn mower to mow the lawn.

My issue is that there isn't always a tool, but the Go worldview forces there to be one:

What reads a book? A person, or a ...?

mannschott• 3 years ago

I've always suspected that 'Reader' and 'Writer' were names borrowed from Oberon since that's one of the influences that contributed to early Go design:

https://github.com/Project-Oberon/Source-Code/blob/cf7f6a6cd...

Please enjoy this microdose of historical trivia even though it doesn't answer the question of why those names were chosen (when designing Oberon).

gabereiser• 3 years ago

In defense of Go “er” structure. It’s written this way because you, as the caller, are the reader. It’s almost an Actor pattern, almost… but it definitely takes the side of “when using this interface, what am I?” mentality. Once you realize the API’s were designed for you, the consumer, and not the provider, you appreciate it much more.

layer8• 3 years ago

Java has Reader and Writer as well, and I agree with your critique of that naming.

naasking4• 3 years ago

In a Go interface, a reader doesn't read: a reader gets read from.

It's both. The Reader is reading from an underlying type.

account-5• 3 years ago

I'm having a hard time understanding what the author means by interface given the context they're using it in at the start of the article. I remember not thinking I fully understood the term when used in programming either, or why you'd use one.

Can someone explain for the idiot?

saghm• 3 years ago

I _think_ the idea is thinking of an "interface" as "something that you use as a way to interact with something from outside an abstraction". I'd summarize their argument as reasoning that if the goal of an abstraction is to avoid having to care about the internal details of something, an interface is a way to expose a subset of ways to interact with it, and the more you expand it, the more it exposes the internals of the thing being abstracted. I don't think they necessarily mean this only in terms of programming, but you could apply this argument to a programming language interface; if you use an interface for interacting with something instead of its direct functionality, each additional method you add to the interface exposes more details of the inner value, which makes it less of an abstraction.

Assuming my interpretation is correct, I'm not sure I totally buy this argument because there doesn't seem to be an obvious way to define the "size" of an interface where it holds true. The naive way to define the size would be number of methods, but I'd argue that methods can vary so much in terms of the amount of cognitive overhead they "expose" to the user that it's not very meaningful. Consider the Movfuscator compiler[0], which compiles code into binaries only using MOV x86 instructions because it happens to be Turing complete; as complex as it might be to learn x86 assembly as a whole and start writing programs directly in it, I'm dubious that trying to do so only with MOV would somehow be easier. Put another way, an x86 instruction set that only contains the MOV instruction is not a "stronger" abstraction than the actual one because it _introduces_ complexity that doesn't exist in the original. Does adding an ADD instruction alongside MOV increase the strength of the abstraction, or weaken it? I don't think there's an answer that we'd immediately all agree on for this sort of thing.

Ultimately, I think trying to measure interfaces through the number of methods they expose is similar to trying to measure code by the number of lines in it; while there are some extreme cases where we'd likely all agree (e.g. for a fizzbuzz implementation, having 10 lines of code is probably better than thousands of lines of code[1]), we can't really come up with a good objective metric because the "target" number is based on the complexity of what you're trying to define, and we don't have a way of quantifying that complexity. I think the ideas here are still super interesting though, not because they have definitive right or wrong answers, but because thinking about stuff like this overall improves one's ability to write good software for usage by other programmers.

[0] https://github.com/xoreaxeaxeax/movfuscator [1]: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

taeric7• 3 years ago

This runs the risk of being reductionist to the point of useless. Is akin to the idea of "do one thing," or "single responsibility."

The danger is these all fail to grow. Or, rather, for them to work, you have to force the growth on either side.

Consider, you are using a writer to write data. How much can you write before it has to slow down? How do you signal broken data connections? How do you resume a previously stopped writer? How do you stop a writer?

Most of these do not have universal answers. But it gets worse. The main abstraction there was the symbolic byte. How do you convert your code's data to bytes? Is that stable? As in not changing.

So, you can have choke points of small interfaces to connect things. But to make that work, you have a lot to do on both sides.

stinkbutt2• 3 years ago

its a misconception that single responsibility is about doing one thing. in fact the principle allows for a system to do many things, but the idea is that it should only serve a single actor.

taeric7• 3 years ago

I assert it is misguided to cling to any view of these as a fundamental truth. They are modeling tools. As such, use them for their usefulness. Don't chase truths with them, at they are tools, not truths.

whstl2• 3 years ago

Calling it a misconception is not really fair.

The "serve a single actor" is a recent revision of the principle by Uncle Bob, from a 2018 book, AFAIK. That's almost 20 years too late (if going by the sources I can find).

I can't find mentions of "actors" or similar terms in Agile Software Development or Clean Code. Pretty much every pre-2018 literature says that SRP relates to modules "[having a] single reason to change", or "[not having] too many responsibilities". The examples are always fuzzy and imprecise, but in the books the principle essentially boils down to class/method size. There are no examples in Clean Code or ASD relating to this new meaning, nor mentions of "actors" or "stakeholders", and until recently there's rarely any article contradicting the original meaning of SRP.

This revisionism seems to come first from backlash from part of the programming community, and also an adaptation of the more recent "one team per microservice" rule.

But the damage of almost 20 years of SRP being taught the way it was in the past was already done.

paulddraper2• 3 years ago

The principal is correct: "the bigger the interface, the weaker the abstraction."

But perhaps you feel there is an second implicit, prescription: "Your abstractions should be strong."

And that's not necessarily true. To every thing there is a season. Excessive abstraction is astronaut architecture.

---

The principal is a good one.

The bigger the interface, the weaker the abstraction.

That's not to say big interfaces are bad or inappropriate. It's just to say they aren't strong abstractions, so don't expect them to be.

taeric7• 3 years ago

Totally fair. I am riffing off the idea that stronger is better. Weaker is worse. Fairly common framing, I thought

But in the spirit, how is a single method "stronger?" Usable in more places, maybe? Often hides too much, such that it really can't be used everywhere.

Describes more things? Well, yeah? But not in meaningful way. At this level of "abstraction," a car is indistinguishable from a bike. Certainly fair for some contexts. Not many relevant ones, though.

And it is that last, that I think sticks. What is the most you can stick to an abstract set of capabilities? That will give you the most utility.

It does mean the cost of implementation raises. But that is realistic?

Makhini• 3 years ago

It's principle, not principal.

yegle• 3 years ago

The standard solution to this problem is a so called "interface smuggling".

You can implement more advanced interface types of the initial interface does not provide the required abstraction, and then do type switch at runtime and gradually switch your code to use the newer interface.

The name of this technique is from https://utcc.utoronto.ca/~cks/space/blog/programming/GoInter...

Too2• 3 years ago

A bit like duck typing.

ben0x539• 3 years ago

Doesn't that frequently run into other code that well-intentionedly wraps a value of the original interface adding new functionality but not passing through the newer interface, because it simply can't account for all interface smuggling that might be going on? Does sophisticated Go code just not use decorator types like I've run into?

mayoff• 3 years ago

This lesson is applicable to lots of languages, not just Go. For example, looking at Swift (where the equivalent of an interface is a protocol), we find many protocols in the standard library that either have one function requirement, or add one function requirement to a parent protocol:

- Equatable requires ==

- Comparable extends Equatable, requires <

- Hashable extends Equatable, requires hash(into:)

- Identifiable requires id

- Encodable requires encode(to:)

- Decodable requires init(from:)

- CustomStringConvertible requires description

- LosslessStringConvertible extends CustomStringConvertible, requires init?(_:)

- CustomDebugStringConvertible requires debugDescription

- CaseIterable requires allCases

- Sequence requires makeIterator()

- IteratorProtocol requires next()

- TextOutputStream requires write(_:)

- TextOutputStreamable requires write(to:)

- CustomReflectable requires customMirror

- CustomPlaygroundDisplayConvertible requires playgroundDescription

- AsyncSequence requires makeAsyncIterator()

- AsyncIteratorProtocol requires next()

And Apple’s Swift-only frameworks also have major single-function protocols:

- SwiftUI.View requires body

- SwiftUI.Animatable requires animatableData

- SwiftUI.TimelineSchedule requires entries(from:mode:)

- SwiftUI.EnvironmentKey requires defaultValue

- Combine.Publisher requires receive(subscriber:)

- Combine.Cancellable requires cancel()

- Combine.Subscription requires request(_:)

klabb3• 3 years ago

I sorta kind of agree with where the author is going, but I think that’s because I know Go and this works quite well in that language. But if I pretended to not know Go, this doesn’t make too much sense on its own, in an arbitrary context.

Even in Go, there isn’t such a strong correlation with interface size and “abstraction strength”. For instance, io.Reader and io.ReadWriteCloser are subjectively similar in terms of “strength”, it just depends on what you’re building. One of the “strongest” abstractions is net.Conn which has 8 methods, which is a lot. In fact, http.ResponseWriter was too small and an ongoing annoyance for years. Only recently was this flaw addressed with http.ResponseController.

Instead, I suspect that Go interfaces are powerful mostly because everyone and their grandma uses the same interfaces, thanks to (1) a std lib with opinionated interface definitions and (2) that the language itself is very focused on “one way” of representing things (no function coloring, for instance). This allows for eg a vast ecosystem of http middleware, that isn’t tied to a specific http server.

Indeed, whenever you venture outside of std interfaces, their appeal really starts waning. They’re fine, but the being seamlessly interoperable within the larger ecosystem is, in my view, where the magic is.

js8• 3 years ago

I like Eric Meijer's take on this. He said that the important property of interface are not the actual method signatures, but rather laws that the methods follow when being called.

I think it follows that with bigger interface, there are more laws to follow (for example, read() must be called after open() but not after close()), and as a consequence, utility of that abstraction gets more limited.

mikhailfranco• 3 years ago

With the corollary that the laws are complete.

YAGNI takes a back seat to algebraic closure.

dmvdoug• 3 years ago

So you list all the things that the ideal version of yourself must have and a long list of things you must do. But to make any progress on your goal, you have the cognitive load of keeping track of all the requirements you’ve put on yourself. I speculate that this is why many New Year’s resolutions fail; the abstraction for building your future self is weak.

Or people just pop them off their stack willy-nilly because it’s a vague tradition to do so. Because most people who are old enough to be serious about a “New Year’s resolution” also are old enough to understand that if you really want to accomplish something or change something, it takes time and dedication and not just pinky-swearing at midnight over champagne.

Also, not to nitpick, but the reason people make lists of things to get done is so that there is literally no cognitive load in keeping track of them. And it’s a weird pivot to go from people have a lot of things they think they want to accomplish to writers write and runners run (literally cases where people have only one thing they want to accomplish).

The framing of this piece was so weird.

dgan• 3 years ago

I have this analogy stuck with me: «Classes should be deep, not large». Which means: imagine a thin rectangle, but very tall, which stands on its thin side up; now, the X-dimension is the price you have to pay upfront to understand an abstraction ("interface") and Y-dimension is what you get once you understand it. The ratio between the two is the "leverage" you get from that abstraction.

Now imagine a perfect square: you gain as much "leverage" with your abstraction as you get functionality out of it: this the prime example of your dumb setter in Java, because it takes you exactly the same effort to learn what it's doing, as for you to do it yourself.

Again this is a picturesque analogy.

diarrhea• 3 years ago

I don’t know if that book originated the idea, but your description fits closely to Philosophy of Software Design.

henkelibonk• 3 years ago

Similarly, the leverage or “reusability” equals complexity of the implementation divided by size of the interface

amelius• 3 years ago

So the DOM is a really weak abstraction?

Capricorn2481• 3 years ago

I don't know what you're referring to. I don't think parsing an entire page of text, selecting an element, and returning it as an object you can manipulate represents a weak interface

naasking4• 3 years ago

Arguably, yes. You can only use the DOM in contexts where you need exactly that DOM.

That said, "weak" is a poor descriptor for this property.

delusional• 3 years ago

I believe it's time to post this again: https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...

It's important to realize that for 90% of the software we write (all the stuff that's not frameworks) we do want weak abstractions. We want to bundle stuff exactly because abstractions create complexity and specificity is simple.

naasking4• 3 years ago

That's a weird take, abstractions don't create complexity, they simplify because it requires less context to understand what's going on.

naasking4• 3 years ago

I think "big" and "weak" are poor terms as they're vague. I think the real principle he's describing is something more like "context-free knowledge/rules are more flexible and useful".

The less context you have to consider when using an abstraction or making a decision, the simpler and more general it is. Like his example of "no drinking", there are no contexts in which he allows himself to drink, so it's simple and can deployed in any situation.

In the reader/writer interfaces, there is only a single requirement for reading or writing, the byte array.

smileykenziekv• 3 years ago

It's true that overly large interfaces can lead to increased coupling and decreased maintainability, and I appreciate the practical examples and tips shared to keep interfaces focused and robust.

The bigger the interface, the weaker the abstraction

Related Stories