A collection of abstract patterns(github.com)
github.com
A collection of abstract patterns
https://github.com/perspectivesonatheme/patterns
14 comments
The first thing this reminds me of is http://tvtropes.org/. The subject matter may be a little different, but the idea is the same: cataloging and indexing conceptual information that is relevant to humans.
> Controlled defects
> ...
> hpv vaccine: from a parent's perspective, it can admit that their kid needs to be protected from something that the parent prohibits; it's an admission of weakness of their authority
Interesting example. Could vaccines themselves be considered an example of controlled defects?
edit: I also notice the "Streisand effect" is listed here. If memory serves, that is about an attempt to forbid the distribution of a photo of her luxurious beachfront home—which thus became a much bigger story. But at first I thought it was about her declining any kind of rhinoplasty to avoid tampering with her voice (edit which is hearsay). Certainly there are many "corrective" surgeries which only call much more attention than the original "defect."
Interesting example. Could vaccines themselves be considered an example of controlled defects?
edit: I also notice the "Streisand effect" is listed here. If memory serves, that is about an attempt to forbid the distribution of a photo of her luxurious beachfront home—which thus became a much bigger story. But at first I thought it was about her declining any kind of rhinoplasty to avoid tampering with her voice (edit which is hearsay). Certainly there are many "corrective" surgeries which only call much more attention than the original "defect."
That does indeed fit, using the interpretation that introducing a pathogen in a controlled manner has its own risks, but may prevent the relatively severe effects of an infection. I'll add it as an example in the next push.
These are fairly standard concepts for architects. Engineers deconstruct problems into implementations. Architects abstract problems into the rules that govern them. Both arrive in similar places, but usually for different reasons.
The dichotomy I usually use is between science and engineering. Science is about breaking systems down into components. Engineering is about composing components into systems. This project is very much on the science side of that. It doesn't propose any courses of action or anything. And yes, most of the concepts are pretty standard. The purpose of the project is to put them all out in the open so they can themselves be studied, and also so we can have a shared langauge about this sort of stuff.
> Both arrive in similar places, but usually for different reasons.
Kind of how I take philosophers/scientists to be (and other dichotomies that are variations on that kind of pattern). There's a funny [and highly paraphrased] quote I use from Heinz von Foerster that I think is highly relevant:
"The reductionist eventually comes to know everything about nothing (by way of distinction) - the wholist eventually comes to know nothing about everything (by way of generalization)."
Kind of how I take philosophers/scientists to be (and other dichotomies that are variations on that kind of pattern). There's a funny [and highly paraphrased] quote I use from Heinz von Foerster that I think is highly relevant:
"The reductionist eventually comes to know everything about nothing (by way of distinction) - the wholist eventually comes to know nothing about everything (by way of generalization)."
Yeah, but if you're a functional human being, you don't _need_ patterns.
That's like saying you don't need math. For the most part, in everyday life, that's true, but there are cases where functional human beings disagree, or we find ourselves in novel situations that we don't know how to handle. In those cases, we need new ways to think and communicate. Intuition works great for catching a ball, but you'll need math to land a rocket on mars.
This was my attempt to joke about the fact that every time design patterns in software architecture are mentioned, someone pipes up about how design patterns aren't useful in functional languages because it's all built in.
You don't need math 'the language', but only because your ad-hoc inferences are suitable. You do need math 'the models' because you can't think without those things. The subject of math isn't actually esoteric. It's the community and conventions that are esoteric.
Patterns are descriptors for how things relate, and arguably what makes someone smart or stupid is their ability to parse the dynamics of relationships among things.
There are a bunch of concepts from multiple disciplines that get used in companies every day. Some of them are stupid euphemisms used by managers who don't understand things, but a lot of them are about getting everyone to understand the importance of how one thing affects another.
Here are some:
- elasticity (of demand) - sunk cost - diminishing returns - scale - long poles - optionality - convexivity - long tail - fat tail - short position - indexing (over) - leverage - advantage - decisive power
There are a bunch of concepts from multiple disciplines that get used in companies every day. Some of them are stupid euphemisms used by managers who don't understand things, but a lot of them are about getting everyone to understand the importance of how one thing affects another.
Here are some:
- elasticity (of demand) - sunk cost - diminishing returns - scale - long poles - optionality - convexivity - long tail - fat tail - short position - indexing (over) - leverage - advantage - decisive power
Interesting ... but I still prefer WikiPedia.
Wikipedia is an incredible resource and I have relied on it heavily in the development of this project. But for specific areas, an integrated, specialized approach gives you more control over things like organization, format, and what content to include or exclude.
Upvoted and donated. Some concepts that could really help my day-to-day way of thinking.