When we are talking about galactic algorithms we have long since left the realm of things that might fit on one computer. Some of these algorithms are only starting to become faster on n so large that we have trouble fitting the data in this solar system. At those scales the distinction between the type of RAM is irrelevant. At that point "how long to read memory address X" is pretty much the same as "how long does light take to reach X" which is pretty much "how far to X" which scales with a cube root. (Well, probably a square root if we look at physical limits for weird reasons)
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.
Again, I've heard that countless times on HN. Every time you ask, everyone is 10xing it and building amazing things that will go to market very soon now. But it's been a while; where is it? Somehow, everyone is just sitting on all these revolutionary advances while selling the exact same stuff as they were selling before, with the same warts and the same annoyances. Gmail is the same, Chrome is the same, Photoshop is the same, Slack is the same, Excel is the same... the only thing that seems to have changed is how SWEs feel about their jobs.
To be fair, what revolution were you expecting to see, exactly? You can 10x a "dashboard but with AI" app all you want but it's only ever going to be a "dashboard but with AI" app. And I note that nobody seems to be claiming that the AI helped them create a brand new kind of app.
You might have delivered 10x more code, but did you deliver 10x more value?
Or put another way, are you making 10x more money?
It's easy to spend excess productivity effectively wasting time. Most companies did it before AI, and will continue doing it after.
It's easy to believe you are not wasting time because you have more bugs fixed or more features delivered, but if it doesn't move the bottom line, what is the point?
I mean it doesn't have to bring 10x more value, but it can be a 10x better experience for existing users. There have been so many niche bugs that were never ever fixed because there's more important things to do, but because fixing a niche bug is now 1 click away that really changes the economics quite a bit especially for small teams.
I'm personally working on a product solo that would not be possible without a team of 3-4 people that are all knowledgeable in that field and would take at least 1 year to get it started. It only took me 3 months to get a fully working solution with $1200 worth of AI subscriptions, the value multiplication is nearly x100 here.
a rather poor idea - esp. the frame part, mouse movement is not related to the display frame (rate). The latter can be rather high, e.g. 240Hz which is 8ms. Having a set delay and be in the boundaries (and not leaving it) is a significantly easier solution and easier to test too.
Overall the delay in tooltips (and configurable) has been a feature since the 90s (could set the delay in millis in some UI frameworks)
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 don't think the author took a position on synchronisation at all. He said you have to pick one to abandon of mutability/concurrency/interactivity and that abandoning mutability is horribly slow (because of the need to copy things). And that isn't technically accurate because you can abandon mutability and not copy things. If you have a 1MB int->int associative data structure and need to change one entry, then you can reuse most of the MB (it isn't going to change) and get away with writing a couple of integers.
And that could be substantially faster than a mutable approach when you need to make a genuine copy of the 1MB structure with a small change and keep both, because you can't structure share and you will need to copy the whole MB. Obviously situation specific, and I'm sure there are edge cases where immutable lookup tables fall apart. I haven't met one myself.
I don't disagree with the article exactly, I do think abandoning mutability is necessary. I just don't think his argument that it needs to be slow is good. If you abandon mutability, "copying" data logically is extremely fast because you can skip almost all the IO for large objects. And copying a large object with a small change should be much faster in an immutable language because of structure sharing. Depending on the workload, that might be faster.
reply