doctor_phil

From personal experience in a small (total <10 people) company, we have definitely 10x our product in the last two years. What 4 devs did in 4 years have been dwarfed by what 2 devs were able to do in 1 year with AI. I'm not so familiar with the giant companies, but from afar it seems like they already have practically all the code-writing capacity they wanted anyway. Google could say "let's build a browser" or "let's build a mobile phone OS" or "lets build an experimental Fuschia" and throw all the people they needed on it already.

Wouldn't it make sense to use mouse movement for this. Display the tooltip only if the cursor is not moving (same position two frames in a row).

If you don't copy the data to the other process, then your garbage collection needs to be aware of all processes all the time. I'm not sure if the author would count that as a form of synchronization, but it wouldn't be unreasonable to argue that I think.

I agree, producing a lower bound is possible. It's practically very hard to give a good lower bound though. Many programs do not terminate, so we don't know if they do produce the right output eventually. In practice the best that has been done on Turing machines is that we have now proved which 5-state machines halt and which don't. So proving any lower bounds larger than that is practically impossible.

Overall an interesting blog post, but the author makes this claim several times:

> So you can never close the case on even one candidate, let alone all of them at once, which means the lower bound stays sealed.

Which is simply not true. The specifics depends on what language you use, but let's take Turing machines as an example. Many candidates are easily disproven: ones that halt immediately, ones that have no rule for writing a "1", ones that have no rule for halting and so on. It's impossible to write a program that can handle every possible candidate though.

And if your string is short enough, let's say the string you are investigating is "0011" then you CAN sit down and check all Turing machines of size 4 and lower. This is essentially what the https://bbchallenge.org/ project did.

For Turing machines we have determined if they halt or not for all machines up to 5 states. It is very computationally hard to push this limit further, but we don't know where the theoretical limit is. We have some large upper bound where a Turing machine computes something that we know is independent of ZFC (see Scott Aaronson for more details), but many suspect that the limit is way lower.

Nice, not having bodies on GET has been a pet peeve of mine for a long time. It would be nice to allow bodies on DELETE as well, but that is less of a problem in most cases.

> UBI won't work either because it will lead to [...] extreme levels of invasive control over people's lives and what they can and cannot do

I've never heard this before. I thought UBI would be very freeing and without much control. If it is universal then there needs to be no control of who gets it or not. What am I missing?

I also for a second thought this was Rasmus Lerdorf, the creator of PHP. In my head I just have him as Rasmus L-something, so this guy was just a hash collision. :)

Idris is slightly more mainstream I would say, but not wildy so. If you like the Haskell interop then I'd recommend staying with Agda.

Scala 3 is much more mainstream and has path dependent types. I've only used Scala 2, and there the boilerplate for dependent types was frustrating imo, but I've heard its better in 3.

Wow, this is so cool! Very overwhelming with so many interesting things at once. I wish I had a few months with nothing else so I could surround myself with only this. :)

Yes. Metal. No.

You want to read about "conservation of etendue" for a technical explanation. For an easier explanation, look for xkcd's excellent "Fire from Moonlight".

I don't think this blog post reflects so well on this engineering team. Kudos to them to be so transparent about it though. "We had so many flaky tests that depended on 3rd parties that broke pipelines that we decided on micro-services" is not something I would put on my CV at least.

Link to interview with Anders. (linked from the thread as well) https://www.youtube.com/watch?v=10qowKUW82U&t=1154s

Why does the fix need to remember all the nodes we have visited? Can't we just keep track of what span we are in? That way we just need to keep track of 2 nodes.

In the graphic from the example we would keep track like this:

  low: - high -
  low: 11 high: -
  low: 23 high: -
  low: 23 high: 26
  Error: now we see item 13, but that is not inside our span!

Is this a serious question? From whose viewpoint are you asking?

We have a hard time understanding what dark matter is. There are theories that some of the dark matter could be tiny black holes left over from the big bang, called primordial black holes (PHBs).

How can we detect PHBs if they exist? If they existed in large numbers, would we notice them? The paper says that you would notice a PHB if it went through you, since you would likely die. We are not noticing people dying by mysterious gunshot-like wounds without guns in any large amounts, so there can not be that many PHBs around.

The paper is (weak) evidence against a large amount of PHBs. The paper is also slightly funny.

The author mentions just downloading the audio track. That's a lot less data than downloading any video at all. ;)

I actually haven't tried Nix (or other nix-alternatives) yet. I've seen a lot of complaints about the language, but a lot of praise and love of the idea. I though Guix was the "main" competitor to nix, using a more mainstream language (Scheme). Is that still the case? How would Brioche compare against Guix if you are OK with both Scheme and Typescript as languages?

Preventing accidental privacy intrusion is easy. If you have a fence around your property (or even something as simple as a mowed lawn) then it is quite obvious where your plot starts and where the forest ends.

Someone malicious doesn't care about laws anyway. If they get caught today, couldn't they could just deny that they were there? I don't understand what would change in that case.

The point is that every function is explicitly telling you if it can or can not return null. Your editor and typechecker will tell you if you need to handle null after calling that function.

If you have a non-null returning function that you need to change so it can return null, then your typechecker will tell you all the places where you now need to handle the new null return.

It doesn't need to be a very large codebase before this becomes a very useful tool to help when refactoring.

But a switch and an if-else *is* a matter of algorithmic complexity. (Well, at least could be for a naive compiler). A switch could be converted to a constant time jump, but the if-else would be trying each case linearly.

There are a lot of endgames that are drawn because of stalemate though. Many pawn endgames ( e.g. pawn and king against lone king) are drawn because of stalemate, but would be a win in most cases if stalemate didn't exist.

Sounds like comptime from Zig. There are a few others that does something similar, but Zig probably has most mind share right now.

Just a fyi: your website is not readable on mobile. (At least not on my firefox/android) The text clips to the left. Desktop mode works though.

Bevyengine is open source and very findable by most search engines.

Here is a direct link: https://github.com/bevyengine/bevy

I don't get the American fixation of cars. Isn't public roads a mild form of communism?

Missed opportunity to use V and W as single/double quote? :-)

Nice. I thought that Zig would be a nice language for writing NIFs - but of course Rust would be good too. Cool!

I found this book very helpful as a supplement to "Crafting Interpreters". The BEAM has a lot of interesting features that many mainstream languages don't. I found the parts about processes, tagging, memory and reduction counting (chapters 3-5 and 11) especially interesting.

The book is clearly very unfinished still, but what exists is very good. Got my mind spinning on what a good statically typed language running on a VM could look like.

Past discussions:

https://news.ycombinator.com/item?id=14061985

https://news.ycombinator.com/item?id=23718278

https://news.ycombinator.com/item?id=17003897