Well first, it’s only two syllables :-). (You can pronounce it with three syllables if you want – both the two- and three-syllable versions are standard and in the dictionary – but humans instinctively use long forms for unfamiliar/uncommon words and short forms for familiar/common words. Compare how we all went from “electronic mail” to “e-mail” to “email”. So if we use nursery, then nursery will be two syllables.)
It’s also no more arbitrary than “for loop” or “function” (which are both two syllables as well). We’ve just forgotten how arbitrary those are because we learned them so long ago :-).
I’m not that attached to the name, and everyone seems to instinctively want to replace it when they first see it, which is definitely a downside. But I also haven’t seen anything that was so much better I felt compelled to switch, and the feedback I’ve gotten from actual users is very consistent: “eh, it looked weird for the first hour but then I stopped noticing”. (You can find a number of those posts in the thread I linked above.)
For what it’s worth, I think this mostly demonstrates that humans are very good at getting used to things, and it would be hard to come up with a name where this doesn’t end up happening. The distinguishing factor is probably how well the name “performs” in that first hour (multiplied over many people), moreso than after it.
I personally agree that most of the heretofore-proposed names including “nursery” are fine but not great, and also don’t have very many better ideas.
(I will just link to my favorite thesaurus, which has become as much an extension of my brain as Google.)
Elsewhere in computingland, the word for a group of threads is a “thread pool”, but I’d guess that trying to re-use that here would be more confusing than helpful?
Yeah, one of my major goals when coming up with a name was to pick something opaque and unfamiliar :-). (Also unique, memorable, short, etc., of course.) This contradicts the usual advice that names should be transparent, but that advice is based on the assumption that 99% of the time, we talk about familiar concepts. And as one user said:
Personally: when I came across this nursery thing, I thought, OK, new name, new concept I actually need to think about instead of assuming that I already know what it’s about. Which is exactly what we need to get across.
I guess some of the pushback on “nursery” is just because the first time you see it, you have no idea what it means, and that’s an uncomfortable feeling. But for most people, it is a genuinely unfamiliar concept, and no word is going to fix that on its own. Our terminological options seem to fall on a spectrum from “unfamiliar, seems meaningless” (→ nursery) to “sounds familiar, but misleading” (→ thread pool) to “completely vague and overloaded” (→ scope). So we may just have to accept that any name is going to kind of suck in one way or another, and pick our poison.
(This is summarizing some of the thread I linked above, there’s a lot more discussion there.)
In fact, we don’t even have a good term for “thread”. In a particular implementation one may use “coroutine” because that’s what it is, but here, in cross-implementation discussion we are trying to be more generic. There’s no reason structured concurrency could not work with OS threads or processes.
If you use “thread” as a generic term, people immediately think of OS threads and get confused.
The terminology is a mess: processes, threads, green threads, lightweight threads, coroutines, goroutines etc.
Btw, speaking of structured concurrency on OS process level, I’ve once implemented it in libdill but then I’ve deleted it because it was just too strange and unfamiliar. But implementing it in shell script doesn’t seem like a completely futile idea. The shell, with process groups etc. it’s already almost there.
I’ve not really had a problem with thinking of the nursary as a pool as spawning some form of execution from a pool is a pretty reasonable analogy in my brain. Admittedly there are already threadpools around, but those usually come with the thread bit attached.
As for the thread/coroutine/whatever part, I tend to think of them as “execution context”, as in they’re something which executes with it’s own stack etc. That is a pretty long word, I guess implementations would be talking about something which makes more sense to them, i.e. the actual thing which is doing the execution.