I feel the author loses points (persuasiveness? respect? integrity? I can't think of the word) by not acknowledging what they think accurately happened. What's the word alternative to genocide in this case? "War" with large sprinkles of civilian casualties?
> To defend truth, one must defend vocabulary
I completely agree with this. The decay of words reduces our ability to communicate accurately, which leads then to a myriad of disagreement, misinformation, disinformation, etc.
I think "semanticide" happens often when there's outrage, and there aren't accurate words that carry enough connotation to reflect the emotion and frustration in the speaker. What's the solution in this case? I don't blame the speakers for resorting to it in haste, but perhaps the issue comes when the word abuse becomes well-meditated, and repeated?
Neat idea. Would you say that biggest difference from something like Kysely is the focus on extracting common calculated SELECT targets into methods that can easily be accessed when querying? Or perhaps it's more thorough with providing TS versions of all the SQL syntax available? The list of reference fields/methods in your docs is certainly massive.
First off, I'm a huge fan of Kysely and it's a massive source of inspiration for Typegres.
You've nailed the two big differences:
* Architected for Business Logic: The primary innovation is the class-based model. This is all about co-locating your business logic (like calculated fields and relations) directly with your data model. The cool part is that these methods aren't just for SELECT; they're composable SQL expressions you can use anywhere: in a WHERE, an ORDER BY, etc. The goal is to create a single, type-safe source of truth for your logic that compiles directly to SQL.
* PostgreSQL-Native: The other fundamental difference is the focus on going deep on a single database rather than being database-agnostic. That massive list of functions you saw is a core feature, designed to provide exhaustive, type-safe, and autocomplete-friendly coverage for the entire PostgreSQL feature set. The philosophy is to stop forcing developers to reinvent database logic in their application code.
Philosophically, it's a shift from composing type-safe SQL strings (like Kysely, which is brilliant for its WYSIWYG approach) to composing SQL expressions as if they were first-class TypeScript objects.
Working on a webapp for critically think with others about a problem.
The idea is that you build a diagram that contains all the details about the problem and people's thoughts on it, and it's organized in such a way that it's easy to just keep refining, down to the smallest detail. So you build this concrete, shared understanding, and move it forward and forward, until hopefully y'all can make some best decision to improve the situation.
There's a lot to do. Currently working on UX to allow hiding intermediate nodes and still have indirect edges drawn. Want to add an LLM integration to generate/update diagrams via natural language, which I think will help a lot with usage barriers to using the app.
I wanted something similar for a worldview. I want an app where I can dump all the things that actively go into shaping my worldview and then when someone wants to know why I think the way I do, I will share them the link of my worldview board. We are not famous people to have our memoir written but this is another way to peek into minds of strangers.
That's a cool idea. Seems like there would be a ton of things contained in an individual's worldview, that it'd be hard to build all of it up. Perhaps when you encounter something that makes you think of some core philosophy, you note it and the philosophy, and eventually there would be a loose picture that forms amongst all the relations.
Certainly would be helpful for trying to understand someone else. Not sure if this is totally appropriate, but it does seem like something that a chatbot would be good at combing through to find examples to suggest why one thinks a certain way about a new topic. You could even ask it about your own worldview!
I'm a big fan of modeling causal structures like this - I think having a diagram is a really good way of getting on the same page and making conversations more constructively focused on points that each party can follow and precisely provide counterpoints for. I appreciate reading an article about this! I feel like our society would benefit a lot from investing more in this kind of information management, but it's not particularly flashy.
I'm working on an app[1] for building these structures, centered around problems and solutions, with the addition that each node or edge can have its own structured auxiliary information, e.g. scores for intuitions, argument trees for supporting/critiquing the claims implied by nodes/edges, questions for identifying unknowns. Here's an example[2] of the two diagrams in the article as they'd be in the app. I want it to be easier for our discussions to be constructive, and I think software can reduce the effort required for it.
I think the structure inherently enables each node to be a claim (like "this thing exists"), but that there's value in making a node even if that node's claim is not particularly disagreeable, because the edges to that node might be disagreeable, or to provide more detail about how one node relates to another (e.g. through some intermediate node). In this case, maybe the main value in modeling "Efficiency" is to convey how innovation might lead to profit.
To me, it feels less fuzzy when you assume that all nodes and edges imply their own claims, and that it's just a matter of whether or not those claims are worth arguing. The fuzziness imo is based on the fact that the curator picks which nodes and edges exist, which therefore determines which claims exist and can be agreed or disagreed with, not to mention the overall legibility of the graph itself. But I would argue that a causal graph like this is better at representing reality than something like an argument tree, and that, while it might be fuzzy to determine which nodes should exist, at least there's less opinion involved about where nodes should be placed in relation to each other. Which imo makes the structure easier to refine given time and feedback.
> I want all teams to squash merge their feature into master after tests pass. One commit at the end, and one commit to remove in case of an issue affecting customers related to the release.
Hmm what's the issue with the GitHub default of merging PRs, where there's a merge commit which individually pulls in the PR's commits? You can revert the merge PR as a whole, or the PR commits individually. E.g. with this[1] merge commit, you can `git revert 0a98f570 -m 1` (the merge commit) or `git revert b30950fc` (an individual commit from the PR).
I agree that wealth is not the same as class, but just as a counter anecdote, my dad is a (small business) plumber and I never felt like we were treated less than any other middle class family. If anything, it seemed like people were often really grateful and giving random gifts like food from gardens or tickets to local events.
In America, a skilled tradesman is middle class. There would be no reason to treat a member of the group any differently. (Incidentally my grandpa was a plumber.)
A teacher is lower upper class though. Teaching is used by some as an early step to a political career — I have a couple of friends who have done so. They don’t have an upper class income, but teachers have the merits to be high class.
> If anything, it seemed like people were often really grateful and giving random gifts like food from gardens or tickets to local events.
If they didn't do that to other middle class families then they saw you as less than them. Seeing people as less comes both with charity and contempt, not just one of those.
I'm building an app[1] (repo[2]) that helps you visualize perspectives and details about complex problems so that it's easier to figure what to do about them.
Right now it's basically a diagramming app specifically for the domain of problem-solving. I think an issue with it is that it's too hard for new users, so I've spent the last few weeks UX designing a view (figma prototype[3]) that I think is more intuitive to use (though sacrifices some features).
I'm currently working on code design for this view and am hoping to implement in the next few weeks!
> Destruction is a terrible yet inevitable end that should only be induced to protect the weak and ameliorate suffering, so be just and resolute when you seek it.
I think an issue with this reasoning is that "protect the weak" and "be just" are things that many people (admittedly not all) from "both sides" _do_ want to do, and that reality is often not so straightforward, involving tradeoffs that cannot be objectively evaluated as "just".
Personally I believe that a lot of disagreements in this realm come down to misunderstanding, in which case it's very sad to have to resort to destruction, when better communication and efforts to work together could create agreement or at least compromise. Admittedly resolving these misunderstandings is really hard, and I think a lot of us don't have the skills or tools to do so in a reasonable amount of time.
I abhor destruction and it is troubling that we have ideologues in power who subscribe to the most odious philosophies mankind has created.
Your reticence and observations are astute.
For context, I was raised in a mormon home and have spent most of my life as a scientifically-minded atheist, which makes my recent connection with well-documented spiritual qualia remarkable to me.
The core idea is to ground discussion in a causal diagram that ties together problems & solutions, then each node/edge can have structured details (importance score, arguments, unknowns, relevant facts, etc.) to help clarify & refine the information. It also has some features for working with this information, e.g. comparing perspectives, using a table to evaluate tradeoffs between solutions.
Right now, you basically need to be a power user to get benefit from it, but I've got a lot of ideas for making it smoother, and I'm slowly working through them.
> To defend truth, one must defend vocabulary
I completely agree with this. The decay of words reduces our ability to communicate accurately, which leads then to a myriad of disagreement, misinformation, disinformation, etc.
I think "semanticide" happens often when there's outrage, and there aren't accurate words that carry enough connotation to reflect the emotion and frustration in the speaker. What's the solution in this case? I don't blame the speakers for resorting to it in haste, but perhaps the issue comes when the word abuse becomes well-meditated, and repeated?