Thread by @swardley

X : Thoughts on seperation of concerns?
Me : Hmmm ... it's generally a good thing.
X : Separate data and presentation.
Me : Whoa ... hold your horses, I said generally. Depends upon what you're building and what you're focused on.
X : Explain

Me : Let us pretend we've decided to build the world's first "kitten internet" i.e. to enable kittens to join the digital age for fun and profit!
X : I hope this gets real soon.
Me : I've built a map of our intrepid endeavour!

Me : Now from the map you can see a clear separation of concerns i.e. you don't want to go building the internet or power or machine learning engines etc. You want to use those components from others.
X : With you so far.
Me : But now think about the kitty internet bit ...

Me : ... we haven't a clue how that'll work, how it will interact with kittens etc. We're in pure discovery mode.
X : And?
Me : Go back to Parnas' 1971 paper "On the criteria to be used in decomposing systems
into modules" ...

... it's based upon "a list of difficult design decisions or design decisions which are likely
to change. Each module is then designed to hide such a decision from the others"
X : And?
Me : In the earliest stages you don't even know the difficult design decisions.

... so when it comes to separation of concerns into data and presentation layer etc, that's more of an evolved thing. One it becomes more known / understood then we can separate out and abstract stuff.

X : Ubiquitous Power?
Me : Batteries, RF power transmission etc. Well, at least we're talking about the map. That represented all of 10 minutes.

X : What about code.
Me : Ok, I've added runtime for you. We're getting off the point here, this is not about building kitten internet but trying to explain how in genesis we don't even know what the design decisions are.
X : You started kitten internet.
Me : I wish I hadn't.

X : What about APIs?
Me : Once something becomes pretty well known i.e. we're beyond the difficult design decision, codified a lot and into abstract general patterns from this then APIs become useful.
X : What about in genesis?
Me : An API for something we don't understand?

X : No?
Me : APIs are a tradeoff especially public ones. We restrict our ability to change at this level in return for benefits of componentisation effects at higher levels. You don't API that we don't understand unless you want to fail and annoy a lot of people.

Me : For example (I'm going to regret this), if you take the kitten internet example above and start the project by defining a public API that you'll create then ... well, you're doomed before you've started.