One alternative to an idea maze for sorting ourselves may be for each of us to list principles, so that we can build up some sort of adjacency matrix to figure out who overlaps most with us. Here's a list for myself I came up with after chatting with @Peter Abrahamsen last week, trying to be opinionated rather than bland: • Longevity over adoption. • Implementation matters. - Transparency over abstraction. - Minimize dependencies. No, really. - Minimize number of languages used. - Conciseness of language is secondary. • Rewarding curiosity about implementation should be a first-class design goal. - Doesn’t matter what the architecture is; can others tell what the architecture is? - Encode knowledge first about the outside. Environment/context over algorithms. (tests) - Encode knowledge in the repo. No other place to look at. “Don’t make me talk to you.” - Knowledge automatically complains when it goes out of date. (tests) - Keep it easy to update. (domain-independent traces over domain-specific immediate UIs) - Organize knowledge autobiographically, in a cleaned up version history. (layers) • Make it tractable to delete features. - Encourage more forks. • Don’t charge for software. Messes with long-term incentives. (Charging for hosting/operational services is ok.) Comments most appreciated. I also worry that I'm too verbose in my comments, so feel free to tell me that 🙂

Interesting to consider what principles we as a community generally feel are guiding, which might but don't actually matter, and those about which we tend to have split opinion. For example, let me venture a few guesses: we all feel liveness is important, that types (and type theories) aren't so much, and that there's differing opinions about ease of learning.

I'm actually a counter-example on liveness and direct-feedback UI. It's something to aim for for sure in the fullness of time. But I think the things I mentioned above are higher priority. A more parsimonious stack would have a much easier time implementing and sustaining a direct-feedback interface.

Great! When making any claim, this is the kind of feedback one hopes for. To learn whether there's a more subtle core value that may manifest differently.

This could be a large difficult task, but I think the payoff is worth it. My prediction is that there'd be many different dimensions and goals that would not all fit into clear categories, with lots of overlap and probably spanning multiple unrelated "spaces". There are even different categories of categories: topics, goals, perspectives, mechanisms, tools, languages, features, change for programmers vs change for users/society, etc. However, I think if we do it best to lay it out (expecting a very broad mess of info), we can then start to identify very clear recurring themes of goals, etc., and that could be powerful.

That's interesting. You wrote

Minimize dependencies

Minimize number of languages used

Encourage more forks

where I would probably have written the opposite in my list of principles. Could you elaborate why you chose these principles? Thanks in advance 😉

How about a spreadsheet? https://docs.google.com/spreadsheets/d/12sTu7RT-s_QlAupY1v-3DfI1Mm9NEX5YMWWTDAKHLfc/edit?usp=sharing

Connecting this to an older thread where we also talked about principles: https://futureofcoding.slack.com/archives/C5T9GPWFL/p1527707157000249 I've also updated mine, while we're at it… https://gist.github.com/stefanlesser/ab0cc5a18baa37ad7b4cda63410ed554

@Felix Kohlgrüber: Yeah, I was explicitly trying to focus on areas where I'm likely to disagree with most people. Giving the `diff`s, as it were. That way if someone agreed with me, that would be a very strong signal indeed. All three stem from my basic focus: on rewarding the curiosity of outsiders to a codebase. And that focus splits up into a long-term and a short-term component. In the long term, I think conventional wisdom in those three areas has costs that society consistently ignores. Somebody should explore the other side. In the short term, the prototype I'm building needs all three properties to reliably falsify my hypotheses. • _Minimize dependencies_: because most libraries today are unreliable/leaky, they make it harder for newcomers to tell where to look for answers to certain questions, and they give worse answers ("this function should give this answer but gives this instead", vs "version x of Foo is incompatible with version y of Bar") • _Minimize languages_: because every language used by a project adds to the burden of prerequisites a reader has to know before they can make the small change they care about. • _Encourage forking_: because at a fundamental level what runs on my laptop has no reason to be identical to what the rest of the world runs. Ease of upgrading and merging are secondary concerns. They still need to be solved, yes, and I'm working on that. But designing the way we distribute software to make upgrading easy seems like the tail wagging the dog. My system is harder to comprehend because the hard disk drivers on it are also optimized for running high-throughput servers. It's also harder to get changes that help me merged upstream because the authors care less about my use case. Why not just have a fork that caters to a smaller segment of the market that is more like me, and drop all the bloat that we don't need?