3 ms·

The note about DRY didn't sound like a mandate to ignore it entirely and "duplicate freely". As you said, duplication is a way to ratify that a common pattern e

by sriku 10y ago

The note about DRY didn't sound like a mandate to ignore it entirely and "duplicate freely". As you said, duplication is a way to ratify that a common pattern exists first before putting something in place that captures the pattern. Many young programmers try to anticipate these concepts and end up with some form of over-design. The goal of DRY is not so much to avoid duplication, but to figure out useful concepts in ground-up work. "Beta abstraction" is a useful mechanism for this. Wrote a post capturing some discussions in my org. [1] [1]: http://sriku.org/blog/2016/02/06/beta-abstraction-for-bottom-up-theory-building/ http://sriku.org/blog/2016/02/06/beta-abstraction-for-bottom... edit: I wrote "as you said", but I expanded on what you said instead.

AstralStorm 10y ago
If you do not anticipate concerns and rely solely on bottom up design, you are guaranteed to require expensive rewrites. Plural. It is also as trivially easy to end up with bad abstraction bottom up add top down, usually by not taking measures to uncouple components (also known as leaking implementation in abstraction) Properly anticipating issues takes experience.
- sriku 10y ago
  Thus far, "properly" has been elusive - I.e. we know it when we see it, but not beforehand. It has been easier to instruct people to look at past concerns in similar projects and tick off which ones are relevant based on current constraints and requirements. So it is not a one-time task to set the "properly" needle right, but a continuous one to keep adjusting it as the cases evolve. The way abstractions are usually laid out is by trying to generalize a concept, usually along simplistic lines without attempting to substantiate it. Beta abstraction provides a substantiatable route which could involve a bit of repeating before the abstraction surfaces. For example, the Pixar cars don't form a class hierarchy with a "car" base class - there is only one class "car" and the variety is generated by configuration (need to pull up ref for this, as I read this long ago). This may not be an obvious step for someone not in the domain.

by sriku 10y ago

AstralStorm 10y ago

If you do not anticipate concerns and rely solely on bottom up design, you are guaranteed to require expensive rewrites. Plural. It is also as trivially easy to end up with bad abstraction bottom up add top down, usually by not taking measures to uncouple components (also known as leaking implementation in abstraction) Properly anticipating issues takes experience.

sriku 10y ago
Thus far, "properly" has been elusive - I.e. we know it when we see it, but not beforehand. It has been easier to instruct people to look at past concerns in similar projects and tick off which ones are relevant based on current constraints and requirements. So it is not a one-time task to set the "properly" needle right, but a continuous one to keep adjusting it as the cases evolve. The way abstractions are usually laid out is by trying to generalize a concept, usually along simplistic lines without attempting to substantiate it. Beta abstraction provides a substantiatable route which could involve a bit of repeating before the abstraction surfaces. For example, the Pixar cars don't form a class hierarchy with a "car" base class - there is only one class "car" and the variety is generated by configuration (need to pull up ref for this, as I read this long ago). This may not be an obvious step for someone not in the domain.