Ask HN: What are you learning?

I'm no expert, so the best I can do is point you to the research community gathering around applied category theory.

* A conference series + workshop: https://www.appliedcategorytheory.org/

* A journal: https://compositionality-journal.org/

Check out some of the people involved in organizing these events. Names I've followed include John Baez, Pawel Sobocinski, and Tai-Danae Bradley (all of whom are amazing educators; check out their work!).

Tai-Danae Bradley wrote a pamphlet on applied category theory which is very approachable: https://arxiv.org/pdf/1809.05923.pdf . Also check out Jules Hedges' thoughts on the importance of compositionality: https://julesh.com/2017/04/22/on-compositionality/ .

First - this is an amazing comment! Solid, concise, and really highlights the important stuff.

John Gottman has a number of books on this topic and I'd highly recommend them.

What. A. Minefield.

Here's what we're trying

- When she or I are upset, name the emotion at the earliest opportunity, e.g. "Hey, what you said back there hurt me, and I'm kind of embarrassed to be hurt by something like that but that's how I'm feeling right now..."

- This sounds like a bunch of whiny nonsense, but we've both found it takes a lot of heat out of a situation, and avoids a snide or sarcastic comment that might make things worse later. This is the slow-burn kinda situation.

- Sometimes there's no time to think about that and one of us just exclaims in anger or hurt about something. I don't know what to do about that; it just means there's a lot of work to do afterwards.

- Good luck :)

Edit: oh yeah, this assumes you're both ok having a difficult conversation in the first place. If implied criticism is a no-go zone, then... I wish you even more luck :)

Agree with you. The more vanilla GraphQL you go in the beginning, the more you'll be able to choose abstraction you want on top of that.

If I had to give you just one tip to design your schema: favor simple queries and mutations that do just one thing instead of trying to generalize your use-cases. For example if you want your client to be able to retrieve your Products by id and by name, instead of going for `product(id: String, name: String)` go for `productById(id: String!)` and `productByName(name: String!)` You'll end up with more fields on Query but the Product type stays the same, the arguments are clearer (just one that is required) and you'll get simpler resolvers. To generalize: forget about REST best practices, think about you queries and mutations as functions and write them with the according best practices you would apply to functions.

Funny thing I noticed about gql is front-end developers are generally more comfortable than back-end ones geting the grasp of it as its DNA is really client-focused.

Sorry for the long reply :)

Sure. First, I'd recommend checking out the website of HN user 'triska at https://www.metalevel.at/prolog -- there's more to Prolog itself than most people are ever made aware of.

Frank Pfenning at CMU does some really cool research on concurrency using logical semantics and sequent calculi (https://www.cs.cmu.edu/~fp/). Session types might be the coolest thing out of this particular corner of the field, but there's so much more to explore here.

Going back some decades, concurrent constraint programming (CCP) takes the position that concurrent processes communicate by posting constraints upon a shared store. Vijay Saraswat's ask/tell CCP model has been a real inspiration to me. As best as I can tell, his work is based on forward reasoning, as opposed to Prof. Pfenning's work, which appears to use backwards reasoning (as does Prolog). (There's an interesting duality between the two kinds of reasoning, which I am not at all positioned to opine on.)

Some of the functional work I've seen on concurrency ends up going in a logical direction without realizing it; the more recent LVars papers (Lindsey Kuper and Ryan Newton) build up a lovely abstraction in Haskell that's conceptually the same as Saraswat's ask/tell logical framework, but they don't seem to realize it until several papers in. (It's all fantastic work! It's just a shame the communities have so little overlap.)

Logic programming allows you to model mutable state, and it gives you high-powered tools to reason about how that state changes over time. As a concrete example, you only need term unification and logical variables to get undirected communication channels in a logic program. Unifying a variable with a term in one part of the program allows other users of the variable to match on it and obtain information about that term. In this sense, it goes in the complete opposite direction from functional programming, which eschews state and treats it as something to be derived from a stateless foundation.