The author's explanation should be considered the authority. But it's useful to rephrase things in your own words. If i were describing it generically to someone whose background i didn't know. I would say its
The discipline of constructing small mathematical primitives that model some objective. Then using those to build a richer language (possibly connected to an existing set of semantics). Finally, when the implementation details (how we talk to the computer) have to be flushed out. There is hope that if our models are correct, they will enlightening us to any contradictions.
E.g if I say left is the opposite of right and then later i construct the idea of opposite such that the opposite applied to left doesn't yield a right ill be notified.
The issue, from my current working perspective, is that accurately describing a rich model is often harder than the subset of relationships you need to accurately capture to complete the task. And that the task your trying to do, is often _the wrong one_ in the first place. The result is that i often feel more like its safer to quickly sketch things out then it is to spend to much time on any particular set of relationships.
Just some food for thought to get the ball rolling.
You wrote "questions" in the topic, but where are the questions? There should be a schedule, otherwise how can people know how far into the book the group has gotten?
Chapter 1 kinda ended in a sad note with scarcity of real world examples and all, so I had to skim through the rest of the book to see if there was any hope. Looks like there's some bold stuff in there that's going to be really interesting to try out. Anyway the discussion on abstraction made sense to me and the haskell intro was within my level of comprehension (except for foldMap), so I'm eager to get my hands dirty in Chapter 2.
@frans it's harder to teach with real world examples because they tend to require some specialized knowledge. The example is flipping tiles, but the lesson is that flipping tiles is about modeling relationships and building them up and connecting them to implantations. That idea generalizes to everything. It also means that knowing the domain is as important as knowing the strategy for modeling it. An issue we devs tend to forget.
What is ADD?
The author's explanation should be considered the authority. But it's useful to rephrase things in your own words. If i were describing it generically to someone whose background i didn't know. I would say its
The discipline of constructing small mathematical primitives that model some objective. Then using those to build a richer language (possibly connected to an existing set of semantics). Finally, when the implementation details (how we talk to the computer) have to be flushed out. There is hope that if our models are correct, they will enlightening us to any contradictions.
E.g if I say left is the opposite of right and then later i construct the idea of opposite such that the opposite applied to left doesn't yield a right ill be notified.
The issue, from my current working perspective, is that accurately describing a rich model is often harder than the subset of relationships you need to accurately capture to complete the task. And that the task your trying to do, is often _the wrong one_ in the first place. The result is that i often feel more like its safer to quickly sketch things out then it is to spend to much time on any particular set of relationships.
Just some food for thought to get the ball rolling.
You wrote "questions" in the topic, but where are the questions? There should be a schedule, otherwise how can people know how far into the book the group has gotten?
@Janus Troelsen i mean, feel free to ask questions about chapter 1 in this stream. or make one devoted to a specific question, your call :)
See the calendar for the schedule. ill update it to be a chapter a week. But that's roughly the pace.
Chapter 1 kinda ended in a sad note with scarcity of real world examples and all, so I had to skim through the rest of the book to see if there was any hope. Looks like there's some bold stuff in there that's going to be really interesting to try out. Anyway the discussion on abstraction made sense to me and the haskell intro was within my level of comprehension (except for foldMap), so I'm eager to get my hands dirty in Chapter 2.
Thanks for putting this together!
@frans it's harder to teach with real world examples because they tend to require some specialized knowledge. The example is flipping tiles, but the lesson is that flipping tiles is about modeling relationships and building them up and connecting them to implantations. That idea generalizes to everything. It also means that knowing the domain is as important as knowing the strategy for modeling it. An issue we devs tend to forget.
(deleted)