3 ms·

Since adopting typscript, the way I usual approach my development is that I clearly define data types on ui and then the implementation details tend to reveal t

Since adopting typscript, the way I usual approach my development is that I clearly define data types on ui and then the implementation details tend to reveal themselves. There is a quote I saw somewhere, forget where, but it was basically: define your data structure and the algorithms will reveal themselves.

motorest 2y ago
> Since adopting typscript, the way I usual approach my development is that I clearly define data types on ui and then the implementation details tend to reveal themselves. That is aligned with the basic premise of Domain-Driven design: define a model of the problem domain, and everything else just falls in place. I wonder why these articles reinvent the wheel with functional programming hand-waving when DDD has been screaming this for years.
- PittleyDunkin 2y ago
  > I wonder why these articles reinvent the wheel with functional programming hand-waving when DDD has been screaming this for years. These are two different levels of abstraction. If you're still enraptured by the fundamental mechanisms of computation (i.e. functional programming) you're not going to see the value in trying to figure out the best way to build via composing mechanisms of computation, whether it's functional, imperative, procedural, logic-based, lisp-based, object-oriented, message-passing, whatever. There's a reason why there aren't many DDD frameworks out there—it doesn't really benefit from tying to specific technologies/languages/ecosystems in the same way that the culture of "build shit as fast as possible" attitude dovetails well with the goals of Rails. I don't see why this is surprising; people re-discover old lessons daily, and petty details will always be conflated with broader themes and patterns—it's just how the human brain works. The discussion is what keeps us thinking about those old lessons. This is just a person's blog, not a journal trying to represent an industry.
  - motorest 2y ago
    > There's a reason why there aren't many DDD frameworks out there—it doesn't really benefit from tying to specific technologies/languages/ecosystems in the same way that the culture of "build shit as fast as possible" attitude dovetails well with the goals of Rails. I think your comment fits the "not even wrong" category. It goes beyond nonsense. There is no DDD framework because the very idea of a DDD framework makes absolutely no sense at all. DDD is an approach to software design, not something you build and reuse. DDD is then used to specify what types to define to put together a model of the domain. Again, there is absolutely no point to have a framework to define these. Lastly, DDD defines interfaces for domain services, and imposed absolutely no restrictions on how to define those. This has nothing to do with frameworks. Development speed is also irrelevant and unrealistic. Not even wrong.
jpitz 2y ago
Could it be Linus Torvalds' "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." ?
- game_the0ry 2y ago
  Honestly, do not think so, but its close enough.
  - azornathogron 2y ago
    There's a well known quote from Fred Brooks too: ""Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious."" (Though from your description I suspect that's also not the one?)
gonzus 2y ago
Probably by Fred Brooks, as summarized by Guy L. Steele Jr in https://dreamsongs.com/ObjectsHaveNotFailedNarr.html https://dreamsongs.com/ObjectsHaveNotFailedNarr.html: > Fred Brooks, in Chapter 9 of The Mythical Man-Month, said this: Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious. That was in 1975. Eric Raymond, in The Cathedral and the Bazaar, paraphrased Brooks' remark into more modern language: Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious.

motorest 2y ago

> Since adopting typscript, the way I usual approach my development is that I clearly define data types on ui and then the implementation details tend to reveal themselves. That is aligned with the basic premise of Domain-Driven design: define a model of the problem domain, and everything else just falls in place. I wonder why these articles reinvent the wheel with functional programming hand-waving when DDD has been screaming this for years.

PittleyDunkin 2y ago
> I wonder why these articles reinvent the wheel with functional programming hand-waving when DDD has been screaming this for years. These are two different levels of abstraction. If you're still enraptured by the fundamental mechanisms of computation (i.e. functional programming) you're not going to see the value in trying to figure out the best way to build via composing mechanisms of computation, whether it's functional, imperative, procedural, logic-based, lisp-based, object-oriented, message-passing, whatever. There's a reason why there aren't many DDD frameworks out there—it doesn't really benefit from tying to specific technologies/languages/ecosystems in the same way that the culture of "build shit as fast as possible" attitude dovetails well with the goals of Rails. I don't see why this is surprising; people re-discover old lessons daily, and petty details will always be conflated with broader themes and patterns—it's just how the human brain works. The discussion is what keeps us thinking about those old lessons. This is just a person's blog, not a journal trying to represent an industry.
- motorest 2y ago
  > There's a reason why there aren't many DDD frameworks out there—it doesn't really benefit from tying to specific technologies/languages/ecosystems in the same way that the culture of "build shit as fast as possible" attitude dovetails well with the goals of Rails. I think your comment fits the "not even wrong" category. It goes beyond nonsense. There is no DDD framework because the very idea of a DDD framework makes absolutely no sense at all. DDD is an approach to software design, not something you build and reuse. DDD is then used to specify what types to define to put together a model of the domain. Again, there is absolutely no point to have a framework to define these. Lastly, DDD defines interfaces for domain services, and imposed absolutely no restrictions on how to define those. This has nothing to do with frameworks. Development speed is also irrelevant and unrealistic. Not even wrong.

jpitz 2y ago

Could it be Linus Torvalds' "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." ?

game_the0ry 2y ago
Honestly, do not think so, but its close enough.
- azornathogron 2y ago
  There's a well known quote from Fred Brooks too: ""Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious."" (Though from your description I suspect that's also not the one?)

gonzus 2y ago

Probably by Fred Brooks, as summarized by Guy L. Steele Jr in https://dreamsongs.com/ObjectsHaveNotFailedNarr.html https://dreamsongs.com/ObjectsHaveNotFailedNarr.html: > Fred Brooks, in Chapter 9 of The Mythical Man-Month, said this: Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious. That was in 1975. Eric Raymond, in The Cathedral and the Bazaar, paraphrased Brooks' remark into more modern language: Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious.