mrkeen

I think I would absolutely hate the automap feature, even if they do make it play perfectly with HM - which I suspect cannot be done.

If I try to map (map f) to a list of arrays of lists, I need the compiler to stop me and tell me I'm wrong, not try to pick an implementation that fits (if such a thing is even decidable)

That's the fun of it. Try to find out? Straight to prison.

Good reading the next time you ask "why can't I just mutate when I want to?"

No

Indeed, whenever I reboot (which is very frequently, because Mastodon will only open, not reopen. If I close it, I need to reboot before using it again) I see the tamper detection. It warns me that I'm using GrapheneOS, not Android.

Reasonably happy with GrapheneOS, but the number of bugs (maybe more ecosystem bugs) would make me hesitant to suggest other people rely on it as a communication device.

I have notifications turned ON for WhatsApp, Signal and Telegram. I never receive notifications from Telegram. I have to open that app to see if anyone said anything. WhatsApp and Signal notifications seem to vary between late or never? This is despite a constant notification reminder that Signal has Background connection enabled.

Also I can only send messages to some whatsapp contacts. My messages appear as pending for a while and eventually turn into 'could not send'.

What's the lesson to be learned from Roc migrating from Rust to Zig?

I think companies figured out how to get around the GPL by simply not distributing software.

The user has a right to know what software runs on their machine? Screw that, we'll keep all the software (and now user data too) on our side, and the user can throw rest calls over the fence.

This game was so good, it's as if the developer was given a team of PhD-level experts to work on it.

Graphs centred around the mean do tend to look pretty balanced.

Another name for that 'logical fallacy' is prisoners' dilemma and "never play a dominated strategy".

Even if you don't take it as prescriptive, it would be dumb not to take it as descriptive (i.e. what the other player will do in a situation)

It needs to by mathematical definition. Half of everything is below average.

(Ignoring the complaints of others that they didn't calculate the mean from the whole graph).

I'm not sure how you can make that claim with only 29 years of data without making some pretty big assumptions about the underlying distribution.

Under what circumstances would 29 years be an insufficient mean to compare to the last few years? Precisely those circumstances in which the climate had changed.

This isn't climate, it's weather.

Right, so if someone was in the US and didn't think they should take action (because of China), then the obvious reply is that they should take action on the basis of being part of US+China, whose population is far greater than either US or China.

I'll go you one further. We need a standard higher-level DSL which abstracts over the various competing data access libraries in a portable, declarative way, such that 1) database engines can independently optimise themselves to better handle such a language, and 2) programmers can move between different companies and be expected to already know this language. I propose the name SQL for this.

Joking (but not really) aside, EF seems to be the easiest way to shoot yourself in the foot, and write code which you think is transactional, but is not actually transactional, and would be transactional if expressed in pure SQL.

It's the corollary to your statement about the market rewarding competent companies.

The market punishes incompetent companies.

Just being aware that the market rewards competent companies is not enough to magically turn companies competent.

The market does reward proficiency. We live in the punished timeline. No contradiction. Most software is buggy and most businesses fail.

Terrific writing. Just terrific. Copied verbatim:

  The Lindy effect in software The longer a tech has been around, the more robust it is seen as compared to more recent ones, we often talk about a technology’s maturity The C language SQL has been around for a while, https://antonz.org/fancy-ql/ JS libraries seem to come and goes

Work is outside.

Workers are demanding to stay inside (with their AC) instead of going outside.

The problem is you can't choose which side the gun nuts end up on.

And yet people were happy to call Snowden a traitor for breaking the news of it.

  in this day and age, are there more useful concepts that we could be giving more attention than CAP, ACID, and friends? Are they useful enough to satisfy the dfsdt principle? I think not. 

- people consciously declare that they have beaten it (in which case you have a very strong launchpad for your rebuttal, e.g. "Are you just pretending P won't happen?")

- or that they are sleepwalking into a software design which implicitly requires CAP capability to function well (in which case you know ahead of time that it will not function well, and so you should choose a different design).

ACID is a useful shorthand for "Can I rely on single-threaded reasoning while writing this multi-threaded program?" E.g. If I transactionally subtract 5 over here, and add 5 over there, then my code will not have changed the total amount. Since we now know DB vendors operate by default in a weaker isolation mode, we have a shorthand for knowing we can't use use single-threaded reasoning, and instead need to consider which commits over there will change the state of the running transaction over here.

We're currently running a long-term offshore experiment to see if 2A has any measurable impact on dragnet surveillance and the NSA.

They're still right here in sibling comments

Are you arguing that most teams that recognise a need for a distributed system chicken-out and use a single node instead, and if so, is that a good thing?

Agreed. When they describe the advantages over Raft, I can't help but read 'this is Paxos'.

I expected to see mention of the Church-Rosser theorem, which may have just turned 90 years old. Pretty good vintage for a comp sci theorem.

Anyway the way I learned it is:

* for a given lambda expression, all evaluation orders which reduce to a normal form will reduce to the same normal form.

* if a lambda expression has a normal form, the 'lazy' way (normal order, leftmost-outermost-reduction, call-by-name, call-by-need) will find it.

Actually on re-reading, the article did mention confluence of the untyped lambda calculus, but only went as far as saying that the different evaluation order leads to different termination results, which is not quite as strong as saying the lazy way will find the terminating path if it exists.

I mean if I was only going to use 'one thing', it would be tech that doesn't have downtime when you replace its parts. Something like Kafka or Cassandra. Then since postgres is useful, I would likely end up adding it into the system.

The reason for separate systems is that some of them go down. And by "go down", that includes you wanting to deploy a new version. Or restore from backup as the article suggested.

You should try more languages