rafd

Having a random quantum seed to an otherwise opaque internal process is still a far cry from free will and agency.

Consider thermodynamics: even without quantum weirdness, we can't compute/predict the micro interactions of atoms in a gas. But most average out, and we can make a lot of meaningful predictions on a macro scale.

Back to brains: even if there is some underlying quantum process that might free us from full determinism, on a macro level, it might not matter - you're still gonna value what you value, and make the same "choices".

And if in some cases a "decision" is actually impacted by some quantum effect... is it "agency"? Or just yet another external process affecting us?

Terry Bouricius (Vermont politician) has a draft book on this topic (link below). He used to be a strong advocate for electoral reform, but after seeing Citizen Assemblies in action, now advocates for Sortition.

He has some interesting ideas about how to structure a modern government with sortition - it wouldn't just be replacing the House and Senate with randomly selected representatives, but, instead: having more smaller bodies with more limited scope (ex. a body for defining the rules of bodies), and spinning out a new group for every major law proposal.

My favorite discovery on this topic (mentioned in the book), were letters between the Founding Fathers of the US where they explicitly discussed not having "democracy" in the United States, because it would give too much power to the people, and so they purposefully chose an election based system because it allowed for elites to retain control by using money to run campaigns (note also: "democracy" at the time referred exclusively to Athenian style democracy).

https://democracycreative.substack.com/p/the-trouble-with-el...

Mario Kart 8 is now frozen, no more patches to come.

We, as in humanity, haven't even figured out how to support the people we already have. We never have. Even without the threat of climate change, billions are under-nourished.

High tech might alleviate some issues, but the root cause could be addressed through existing social technology. For example, say we had AGI robots that could do all the work that humans do today - if owned only by rich capitalists, the quality of life for many may actually drop. But, combined with land value taxes and universal basic income, the result would likely be an increase quality of life (unless it turns out humans are willing to keep increasing population as long as the amount of aggregate suffering is below a certain level). AGI robots don't necessarily make things better. But social tech like LVT+UBI could meaningfully make things better, and, it could do it today (without the need for more "geniuses").

Also: friends don't let friends use line graphs when the data is not continous between the sampled points.

(bar graphs are typically more appropriate)

It's typically easier to make money from concentrations of money (rich individuals and companies), and those tend have more gain opportunities than problems (because they've already monied-away their problems).

Starting with "problems" is already cutting out half of the kinds of businesses that exist.

I much prefer the "jobs-to-be-done" framing: people and organizations desire certain things done, and they pay for products/services to get them done; some jobs are not being well done (and thus, a "problem"), but many jobs are being done fine, but, there may still be opportunities to do them much better. (aka "pains" and "gains")

Ex. Alice was fine with her extra bedroom but AirBnB allowed her to make an extra 2k per month? etc

Its often easier to find acute pains to address than great gain opportunities, but it is possible, and many startups do it. Ignoring gain-potential as an avenue of value creation is myopic.

I made a tool like this for our team a while back, and made it available for free: https://decidedly.so

Would love to hear your thoughts or anyone else's.

(Fun aside: I ended up implementing the Ford Johnson algorithm to minimize the number of comparisons, explanation here: https://github.com/decidedlyso/merge-insertion-sort )

FYI now there’s also :user-invalid which waits for the user to blur out of the field before it indicates the validity.

This only follows under the assumption that a company only derives value from the labour of its employees, ie. “there is only labour”.

But there are many other kinds of assets - cash, brand, real estate, natural renewable resources etc.

One could have a zero labour company that is profitable.

...and, there's nothing particularly preventing a similar approach in JS (keywords would need to be strings, and... data manipulation in JS is relatively a huge pain compared to Clojure)

For anyone interested in a slightly lighter Diplomacy, I recommend checking out Game of Thrones the board game. Like Diplomacy, it can be played with no randomness, but the way orders work is much less tedious. It ties in nicely with the themes from the books. It is still pretty intense, so more for the Risk crowd than the Catan crowd.

If we could afford to live in a world where everyone was given $5000/mth, would we want such a world? (where work was optional) I think yes.

...can we afford that? At this point, probably not. But is it something to strive for?

I think it is eventually possible to get the costs of providing basic needs to everyone (say, through automation) to the point where they can be easily covered by taxes on those who choose to work.

I fear though, that housing is an obstacle to this vision, because in many countries, people rely on housing to be an investment (ex. my parents house is the majority of their retirement), and so the politicians protect it as such, and developers have weird incentives... and so the prices don't go down.

Some scarce things that everyday people want are likely to go up in price (ex. rent in cities that are already struggling with housing prices).

Some things may drop in price (higher demand allowing to spread fixed costs over more units; or, lower volatility allowing for smaller margins).

Some prices that would increase, may only do some temporarily, as the market catches up with production or competition (ex. greater stable demand for basic housing makes it less risky to build said housing, so more of it gets built).

Existing social insurance schemes typically are of the form: you get $1000/mth, but, if you do any work, it subtracts from your payment. So, if you work less than $1000/mth, you're working, say, 100 hours "for nothing".

To make it worse, there is often an income point where the payment goes to zero (ex. if you make more than $800, you are no longer eligible, leaving a $200 gap). Or there are certain benefits that are lost (child credits, transit credits).

With UBI, you get $1000, but then every hour worked puts more money in your pocket.

Ctrl-H , or, in project.clj, remove the line ":preloads [day8.re-frame-10x.preload]" and restart the REPL.

I hear your concern. Would the ability to "disable auto-creation of tags" solve your problem?

If you're using Slack/etc. primarily for "optional conversations", where not-reading or not-participating is no big deal, then Braid's design adds nothing for you.

But, if you are trying to have necessary conversations with your remote team, make decisions, etc., then I think Braid's approach helps.

Say in Slack, in your team's #dev channel, a conversation starts: "should we do X or Y for this feature?" with several replies. A few minutes later a new conversation starts "for this other thing...", more replies. And maybe a few other topics.

You happened to have been on a call for the last hour (or getting some focused coding done) and pop into the channel to see 50+ messages spanning 4+ conversations. Hmm... it looks like your colleagues overlooked something important about topic #1, but, the last 40 messages have been about topic #2, #3, #4, and they're currently talking about #5. You can try to restart the conversation about topic #1 (interrupting the current in-progress topic), or try to juggle multiple topics in the same room at the same time. It's doable, but it's a mess. The more active the channel, the harder this is to do well. Result: you train yourself to keep checking so you can participate at the right time.

If everyone was using Slack's threading ability, this would less of a problem, but, in practice, Slack's threading UX is an after-thought and I see Slack threads being used rarely.

Braid allows you to be a part of multiple separate simultaneous async conversations "in the same channel" (we call it a tag).

Not at the moment, but it is a pull-request away. :P

I'll put adjustable-width-threads on our roadmap. ...but if anyone reading this wants to work on it, it would make a decent 'first PR', and I'm available to pair remotely to help you get started. (email in profile)

Re: letting them go... I guess it depends on how you use chat. For us, most conversations in Braid are bonafide work conversations that are important and can't be skipped (ex. we run our board meetings asynchronously via Braid, discuss major product decisions, etc.)

The way I see most Slack used most of the time, though -- as a digital watercooler -- I can see why it's fine to skip most conversations.

Re: tech; it's clojurescript front-end; clojure backend.

With "Datomic On-Prem Starter", you can run Braid for free.

https://www.datomic.com/get-datomic.html

The UI is based on side-scrolling, which works best with trackpad, but, I use a mouse and it works okay.

In practise, I tend to go through conversations 1-by-1 and either reply and close them, close them without reply, or star them and close them (for review later).

Re: whack-a-mole, you control which tags you're subscribed to and you can mute message threads you're not interested in, similar to how you can mute channels in Slack.

"multiple conversations all jumbled up" is exactly what initially motivated me to start hacking on Braid.

Braid's search is certainly something that can be improved. In practice, it's actually pretty rare to have to fish for something in the archives, because you tend to keep relevant conversations open until you're done with them. (We also have "starring", like in Gmail, so that you can move conversations out of your inbox, but still keep them easily accessible).

On a day-to-day, a good "search" experience might actually be more relevant for slicing-and-dicing through your Inbox (ie. triaging the firehose of daily messages), rather than digging up old messages.

Hey HN! One of the creators of Braid here.

We started Braid internally in the pre-Slack days (we were using HipChat then), because we felt that "chatrooms" didn't promote good async team workflows. They would lead to a lot of FOMO and constant checking, because if you didn't participate in a conversation at the right time, the topic in a channel would have moved on to something else. We liked the async nature of email more, but, email has it's own baggage.

Our team has been using Braid internally for several years and we're very happy with it. But, compared to Slack, it's best thought of as a prototype / experiment / UI-proof-of-concept, because we don't have the polish and maturity of features that Slack has.

We've had interest from some individuals who "get it", but it's often been hard for those individuals to convert the rest of their teams. If any team here is interested in the Braid concept and wants to give it a serious go, I'm at your disposal, and I'd love to get your feedback so we can keep morphing the product.

The use of "hashtags" in our demos is a bit overdone compared to what happens in practice. It makes it seem like twitter #hastags, but, it's really more like Gmail labels. Braid tags serve the same purpose as Slack's channels, except a given thread can exist in multiple channels (ie. go to multiple teams / individuals) and tags can be added over time (ie. more people can be invited to the conversation).

Thanks a lot for doing this!

Here are the slides: https://docs.google.com/presentation/d/13nRcrbnbvpUZGtABY9UC...

Also, I gave the talk again and made some modifications (focusing only on FP, no mention of Clojure), here are the slides and notes: https://docs.google.com/presentation/d/1NRtJvV5bXZSpFe41i3Oh... https://docs.google.com/document/d/1VSCPIy_Zs04z9xThufmRO4nc...

The introduction was changed to focus on Functional Programming, explaining a bit more what it is and what pure functions are.

The refactor was changed to mark the use of Math.random() as being side-effectful / impure, and then added a few refactoring steps to account for that.

6 characters is pretty trivial to brute force. Someone could set up a script to continuously try all combinations and get access to whatever happens to hit a match.

You could block an IP after a certain number of failures, but that doesn't protect against a network of various IPs attacking (which attackers often have access to). Adding an artificial delay also wouldn't protect against parallel attacks.

A simpler/better solution would be to add a few more characters to the shortcode so it's infeasible to force within your timeframe (and the number of requests your servers can handle in that timeframe).

The difference is that in the cljs version you are writing clojure at all times using clojure data structures and types (vector, map, keyword, string) which lets you manipulate and generate things easily, and, you don't have to jump between "jsx" mode and "JS" mode.

My game group's version of the take-backsies rule is: you can change your decision, as long as no new information has been revealed (a card revealed, a dice roll, next players move, etc.)

We also play with "public information stays public" for most games.

I think "infrastructure" in that every other app that might integrate with a CRM has a salesforce integration.

Also, you can expect sales hires to know salesforce.