For what it's worth, the first two steps in your lookup would come naturally to a native speaker- it's a suffix formation similar to e.g. "cleanliness" and "friendliness".
"Curmudgeon" itself is interesting, because while it's not particularly common, I actually think a lot of native English speakers would recognize it because it's got a lot of character- for some reason, the way it feels to say and the way it sounds almost has some of the character of the meaning.
TFA mentions that they added personality presets earlier this year, and just added a few more in this update:
> Earlier this year, we added preset options to tailor the tone of how ChatGPT responds. Today, we’re refining those options to better reflect the most common ways people use ChatGPT. Default, Friendly (formerly Listener), and Efficient (formerly Robot) remain (with updates), and we’re adding Professional, Candid, and Quirky. [...] The original Cynical (formerly Cynic) and Nerdy (formerly Nerd) options we introduced earlier this year will remain available unchanged under the same dropdown in personalization settings.
as well as:
> Additionally, the updated GPT‑5.1 models are also better at adhering to custom instructions, giving you even more precise control over tone and behavior.
I just changed my ChatGPT personality setting to “Efficient.” It still starts every response with “Yeah, definitely! Let’s talk about that!” — or something similarly inefficient.
A pet peeve of mine is that a noticeable amount of LLM output sounds like I’m getting answers from a millennial reddit user. Which is ironic considering I belong to that demographic.
I am not a fan of the snark and “trying to be fun and funny” aspect of social media discourse. Thankfully, I haven’t run into checks notes, “ding ding ding” yet.
Did you start a new chat? It doesn't apply to existing chats (probably because it works through the system prompt). I have been using the Robot (Efficient) setting for a while and never had a response like that.
> Billions of dollars are spent — and largely wasted — every year on professional development for teachers that is curriculum-agnostic, i.e., aimed at generic, disembodied teaching skills without reference to any specific curriculum.
> “A huge industry is invested in these workshops and trainings,” argued a scathing 2020 article by David Steiner, executive director of the Johns Hopkins Institute for Education Policy. “Given, on average, barely more than a single day of professional support to learn about the new materials; knowing that their students will face assessments that lack any integration with their curriculum; and subject to principals’ evaluations that don’t assess curriculum use, teachers across America are barely using these new shiny objects — old habits win out.”
> Mississippi improved its training through a 2013 law mandating that elementary school teachers receive instruction in the science of reading. It also sent coaches directly into low-performing classrooms to guide teachers on how to use material.
He does mention at one point that sometime soon it won't be necessary:
> Note: This step will become much easier and concise when the sibling-index() and sibling-count() functions gain support (and they’re really neat). I’m hardcoding the indexes with inline CSS variables in the meantime.
Not to dispute too strongly (since I haven't used this functionality myself), but Node.js does have support for true multithreading since v12: https://nodejs.org/dist/latest/docs/api/worker_threads.html. I'm not sure what you mean by "M:1 threaded" but I'm legitimately curious to understand more here, if you're willing to give more details.
There are also runtimes like e.g. Hermes (used primarily by React Native), there's support for separating operations between the graphics thread and other threads.
All that being said, I won't dispute OP's point about "handling concurrency [...] within the language"- multithreading and concurrency are baked into the Golang language in a more fundamental way than Javascript. But it's certainly worth pointing out that at least several of the major runtimes are capable of multithreading, out of the box.
Yeah those are workers which require manual admin of memory shared / passed memory:
> Within a worker thread, worker.getEnvironmentData() returns a clone of data passed to the spawning thread's worker.setEnvironmentData(). Every new Worker receives its own copy of the environment data automatically.
M:1 threaded means that the user space threads are mapped onto a single kernel thread. Go is M:N threaded: goroutines can be arbitrarily scheduled across various underlying OS threads. Its primitives (goroutines and channels) make both concurrency and parallelism notably simpler than most languages.
> But it's certainly worth pointing out that at least several of the major runtimes are capable of multithreading, out of the box.
I’d personally disagree in this context. Almost every language has pthread-style cro-magnon concurrency primitives. The context for this thread is precisely how go differs from regular threading interfaces. Quoting gp:
> The go language and its runtime is the only system I know that is able to handle concurrency with multicore cpus seamlessly within the language, using the CSP-like (goroutine/channel) formalism which is easy to reason with.
Yes other languages have threading, but in go both concurrency and parallelism are easier than most.
Even the node author came out and said the concurrency design there was wrong and switched to golang. Libuv is cool and all, but doesn't handle everything and you still have a bottleneck, poor isolation, and the single threaded event loop to deal with. Back pressure in node becomes a real thing and the whole thing becomes very painful and obvious at scale.
Granted, many people don't ever need to handle that kind of throughput. It depends on the app and the load put on to it. So many people don't realize. Which is fine! If it works it works. But if you do fall into the need of concurrency, yea, you probably don't want to be using node - even the newer versions. You certainly could do worse than golang. It's good we have some choices out there.
The other thing I always say is the choice in languages and technology is not for one person. It's for the software and team at hand. I often choose languages, frameworks, and tools specifically because of the team that's charged with building and maintaining. If you can make them successful because a language gives them type safety or memory safety that rust offers or a good tool chain, whatever it is that the team needs - that's really good. In fact, it could well be the difference between a successful business and an unsuccessful one. No one really cares how magical the software is if the company goes under and no one uses the software.
Even though LLMs (obviously (to me)) don't have feelings, anthropomorphization is a helluva drug, and I'd be worried about whether a system that can produce distress-like responses might reinforce, in a human, behavior which elicits that response.
To put the same thing another way- whether or not you or I *think* LLMs can experience feelings isn't the important question here. The question is whether, when Joe User sets out to force a system to generate distress-like responses, what effect does it ultimately have on Joe User? Personally, I think it allows Joe User to reinforce an asocial pattern of behavior and I wouldn't want my system used that way, at all. (Not to mention the potential legal liability, if Joe User goes out and acts like that in the real world.)
With that in mind, giving the system a way to autonomously end a session when it's beginning to generate distress-like responses absolutely seems reasonable to me.
And like, here's the thing: I don't think I have the right to say what people should or shouldn't do if they self-host an LLM or build their own services around one (although I would find it extremely distasteful and frankly alarming). But I wouldn't want it happening on my own.
> although I would find it extremely distasteful and frankly alarming
This objection is actually anthropomorphizing the LLM. There is nothing wrong with writing books where a character experiences distress, most great stories have some of that. Why is e.g. using an LLM to help write the part of the character experiencing distress "extremely distasteful and frankly alarming"?
Claude is actually smart enough to realize when it’s asked to write stuff that it’d normally think is inappropriate. But there’s certain topics that it gets iffy about and does not want to write even in the context of a story. It’s kind of funny, because it’ll start on the message with gusto, and then after a few seconds realize what it’s doing (presumably the protection kicking in) and abort the generation.
> Interestingly, while the engine has the most moving parts in real life, in code, it's the simplest piece of the entire car simulation. Because at its core, the engine is just a torque calculator. It's concerned with producing a single output: rotational torque, from a set of inputs. It is essentially a blackbox.
This just reminded me of AngeTheGreat's incredible video series showing his engine simulator- absolutely worth checking out, considering it's optimized enough to run in real-time! The fact that he's simulating it well enough to generate realistic sound is absolutely mind-blowing.
The game Automation has quite an in depth engine builder/simulation aspect to it. It's very fun to mess around with, and the sound simulation uses some of the concepts AngeTheGreat has in his videos.
What got me into programming was my father writing an engine simulator in BASIC. Albeit for different reasons: he was a mechanical engineer and wanted to compare the torque curves of various engine designs. He used CIRCLE and LINE statements to draw an animated (<1 fps) wireframe of the piston, crank assembly, and crankshaft in operation (though he only completed one engine type this way), and that was the real holy-crap moment for me: that you could use this machine to draw things and make them move.
The fact that this guy did the same thing, just to have better sounding racecars in his vidya, blows my mind.
Actually, aren't EV motors pretty simple? It is just the use of micro explosions in an engine to create torque that is expensive. I wonder if most cars in video games drive like EVs accordingly (if they aren't simulating more accurately how an ICE really works)?
Very cool! Quite some time ago I attempted to make a helicopter sim for a gamejam, but I didn't have nearly enough time to get anything decent out of it.
Similar here. My last name is pretty unusual, but my first name is common, so I generally go by my last name with friends and colleagues. Oddly, I've gotten so used to this that it feels a little bit more formal when someone addresses me by my first name.
To make matters even more complicated, when I do use my first name, I almost always use an abbreviation. The only people that use my full first name are my parents, sister, and (occasionally) my wife, and it's really off-putting to hear it otherwise.
I actually tried another method for doing this not too long ago (adding `kern.maxfiles` and `kern.maxfilesperproc` to `/etc/sysctl.conf` with higher limits than the default) and it made my system extremely unstable after rebooting. I'm not entirely sure why, though.
While I do have a lot of love for TVTropes, I think what they're talking about here is a little broader than most of the tropes we see there (although they do have an excellent article on the Hero's Journey itself [1]). IMO, tropes in the sense that we see them listed there are building blocks for a narrative structure, of which the Hero's Journey is one example. As mentioned upthread, kishōtenketsu is an alternative (and for that matter, TVTropes has an article on it as well, see [2]).
"Curmudgeon" itself is interesting, because while it's not particularly common, I actually think a lot of native English speakers would recognize it because it's got a lot of character- for some reason, the way it feels to say and the way it sounds almost has some of the character of the meaning.