Personally I found the article informative and well-written. I had been wondering for a while why Claude Code didn't more aggressively use sub-agents to split work, and it wasn't obvious to me (I don't build agents for a living).
I've done a lot of Erlang and I don't see the relation? Supervisors are an error isolation tool, they don't perform the work, break it down, combine results, or act as a communication channel. It's kind of the point that supervisors don't do much so they can be trusted to be reliable.
It's a wide field so it depends on the specialization. I did computer engineering 15+ years ago and we never touched SQL, but I think the software engineering people did have a class on it.
I'm saying that if I do a regular loop, something needs to explicitly mutate, either a reference or a value itself.
`for (var i = 0; i < n, i++)`, for example, requires that `i` mutate in order to keep track of the value so that the loop can eventually terminate. You could also do something like:
var i = new Obj();
while (!i.isDone()) {
//do some stuff
i = new Obj();
}
There, the reference to `i` is being mutated.
For tail recursion, it's a little different. If I did something like Factorial:
function factorial(n, acc) {
if (n <= 1) return acc;
return factorial(n - 1, acc * n);
}
Doing this, there's no explicit mutation. It might be happening behind the scenes, but everything there from the code perspective is creating a new value.
In something like Clojure, you might do something like
(defn vrange [n]
(loop [i 0 v []]
(if (< i n)
(recur (inc i) (conj v i))
v)))
(stolen from [1])
In this case, we're creating "new" structures on every iteration of the loop, so our code is "more pure", in that there's no mutation. It might be being mutated in the implementation but not from the author's perspective.
You could imagine a language like eg Python with a for-each loop that creates a new variable for each run through the loop body.
Basically, just pretend the loop body is a lambda that you call for each run through the loop.
It might make sense to think of the common loops as a special kind of combinator (like 'map' and 'filter', 'reduce' etc.) And just like you shouldn't write everything in terms of 'reduce', even though you perhaps could, you shouldn't write everything in terms of the common loops either.
Make up new combinators, when you need them.
For comparison, in Haskell we seldom use 'naked' recursion directly: we typically define a combinator and then use it.
That often makes sense, even if you only use the combinator once.
That's rebinding. Mutation is when you change the state of an object. Variables are not objects. You can't have a reference (aka pointer) pointing to a variable.
I don't know if you're referring to a particular language's peculiarities, but it doesn't really matter. It's mutation.
tombert's point (I think) is that in a functional setting, factorial(n) is always factorial(n). In an imperative setting, first it's 1, then 2, then 6, then 24, etc.
Here's factorial calculated imperatively in C#.
public async Task Factorial() {
long primitiveResult = 1L;
Wrapped<long> objectResult = new Wrapped<long>(1L);
var observer = new Task(ObserveVariable);
observer.Start();
for (var i = 2; i <= 15; i++) {
primitiveResult *= i;
objectResult = new Wrapped<long>(objectResult.Value * i);
await Task.Delay(100);
}
observer.Wait();
return;
void ObserveVariable() {
while (primitiveResult != 1307674368000 || objectResult.Value != 1307674368000) {
Thread.Sleep(100);
}
}
}
There are two results (one primitive and one object) to show that it doesn't matter. Maybe there's no such thing as a Reference-to-a-Variable in whatever language you have in mind, but in the above code ObserveVariable refers to a variable (while it mutates).
I mean this is getting into splitting-hairs territory, but I would argue that rebinding is a form of mutation; the variable i is changing as far as the programmer is concerned.
If I were to write
var i = new Obj(2)
// do stuff 1
i = new Obj(3)
// do stuff 2
Then yes, that’s technically rebinding and not directly mutating the value in memory, but from “do stuff 2’s” perspective the value has changed. It still acts more or less the same as if it had directly changed.
If you dereference it you get back an integer, not a variable. A variable is a name that identifies a value; the pointer points to the value, not to the name.
Nope. Loops are unnecessary unless you have mutation. If you don't mutate, there's no need to run the same code again: if the state of the world did not change during iteration 1, and you run the same code on it again, the state of the world won't change during iteration 2.
I recommend https://ferd.ca/the-zen-of-erlang.html starting from "if my configuration file is corrupted, restarting won't fix anything". The tl;dr is it helps with transient bugs.
> if you feel that your well-understood regular failure case is viable, then all your error handling can fall-through to that case.
This is my favourite line, because it generalizes the underlying principle beyond the specific BEAM/OTP model in a way that carries over well to the more common sort of database-backed services that people tend to write.
...and does no harm for unfixable bugs. It's the logical equivalent of "switch off and on again" that as we know fixes most issues by itself, but happening only on a part of your software deployment, so most of it will keep running.
That's not at all what Marcus is saying. He admits that it does remarkably well, but says (1) it's still not trustworthy; and (2) This version is not much better than the previous version. Both points are in support of his claim that just scaling isn't ever going to lead to General AI.
Japan doesn't have a housing crisis. I'm in a great location in Tokyo, the rent is under $750/month, and it's been the same for the decade+ I've been in this specific place.
If there's a problem, it's too many empty homes in aging rural areas. Cities are doing just fine, even with a growing population in Tokyo.
New apartment prices in Tokyo are double what they were a few years ago. [1] The reason is foreign investors buying up loads of properties and sitting on them or turning them into AirBNBs. Locals can't afford them because wages aren't increasing. The concept of buying a property to resell it also isn't a thing amongst locals, so it's clueless rich people and corporations buying up properties and thinking they can flip them, which won't be happening any time soon.
But after a few years of squeezing, locals may have no choice but to pay their entire paycheck to foreign investors. Though thankfully the government is planning to take steps to potentially outlaw foreign buyers. If we're lucky, and some parties get their way, they might just strip the properties from them. If you're not living here, you have no business owning dozens of homes.
My shallow experience of Japan tells me that if there's one country that can regulate the shit of the airbnb problem, it's this one. We're so used in the west to see properties as an asset that only appreciates that we've lost sight of what homes are meant to be. Meanwhile the whole Mediterranean coast is being bought by foreigners with the help of greedy local fucks. I've been told the Portuguese have it much worse even.
Nothing vents off like a bit of class hate, doesnt it. Locals from your description act legally within the limits of the law, if you dont like situation change laws, thats the way for a change.
Everybody maximizes their profit and thinks first and foremost about themselves and only then about the rest. Case point - a better half of this forum works/worked for faangs and their variants who destroy privacy and more of whole mankind for the sake of profit for themselves, and even pat themselves in the back how effectively they helped the 'the goal'.
> if you dont like situation change laws, thats the way for a change
Which is done by protesting and advocating for it. Not being in a "that's the way things are" attitude.
> Everybody maximizes their profit and thinks first and foremost about themselves and only then about the rest.
What a sad way to see life. It is so easy to find countless examples of people doing exactly not that. American individualism really got to your brain.
I see a difference in-between selling your property at current market rate and having a business which relies on destroying the housing supply to make profit. I don't work for companies who "destroy privacy and more" even though it would be in my interest, many of us are not pure profit-maximizers.
> it's clueless rich people and corporations buying up properties and thinking they can flip them
so the original owner got a nice priced deal out of the sale. Then, when said clueless rich person decides to sell in the future due to being unable to hold on to it any more, they make a loss (which is a gain for that future buyer, whoever they are).
> after a few years of squeezing, locals may have no choice but to pay their entire paycheck to foreign investors
why the squeeze? If the airBNB is being occupied, then it simply means the price for the rental was correct, and it was artificially low before (due to the demand not being met for short term stays).
An AirBNB can be occupied for 2 days a week and make more than typical rent.
People who see homes as a mere unit of value meant to be priced on a global scale, and not something people should be living in, are simply inhuman. People in cities around the world are getting fed up with it, with justified protests and even riots happening.
Rentseeking has no limit. Unimaginably rich corporations can buy up every property and leave almost everyone homeless. They can take 90% of the paychecks of everyone else. And they'll say "well prices were artificially low before." No. Now they're artificially high. People in desperate situations pay more and take out debt because they have no other reasonable choice.
The way Erlang does it is to use buckets so it looks like a single queue to the user code but really is more like multiple queues behind the scene. Scales extremely well. It's certainly not "just moving a pointer to a piece of shared memory" though...
reply