Olivier FAURE PoignardAzur

Long-lived callbacks are evil

I poured myself a cup of tea, floated down my books from upstairs, and sat down across from him.

There was no burst of energy or determination in my veins. I felt as frightened and unfocused and tired as I did an hour ago. And I wanted more than anything to get drunk, or play Jao Lu, or listen to the radio or watch something on one of those fancy new television sets.

I sat down at the coffee table, next to Hira. And I flipped open the book.

https://pithserial.com/2020/06/30/7-a-the-blue-charlatan/

Proposal

NOTE: There has been some debate in the past as to what term best describes when a trait can be turned into a trait object with the syntax dyn MyTrait. The current official term is "object safety", but it is widely agreed to be unsatisfying. We use "dyn-safety" in this document.

Summary

Progressively move the language towards having by-default dyn-safety for all traits.
To that end, add a new ?dyn trait qualifier to indicate that template parameters accept a trait object.

"We know that the world is about to be consumed by a giant overwhelming alien organization, so does anything we do matter?"

https://www.lesswrong.com/posts/byewoxJiAfwE6zpep/reality-revealing-and-reality-masking-puzzles#Disorientation_patterns

CONTENT WARNING - SHORT DESCRIPTIONS OF UNETHICAL HUMAN EXPERIMENTS - CHILD ABUSE - MENTIONS OF SEXUAL ASSAULT

Warning - this fic broaches heavy subjects. If you've finished Twig, this shouldn't faze you. Otherwise, heed the trigger warnings. Also, major spoiler for the entire story of Twig.

Notes

Theme: Happens ~10 years after the events of Twig. The Academy is being demolished, press reports on it as a symbol of the new world. Ex-actors from Professor Ferres's show come together and share their perspective. They disagree on how traumatic the experience was.

At the risk of being “that guy”, this isn’t actually true. Encapsulation does not mean that other objects can’t change the states of an object, just that they can’t do so DIRECTLY. They always have to ask the object to do it for them. So, in this case, there’s nothing in OO rules that says that a bank transaction can’t, as a side effect, change the name of the customer. It only can’t do so by reaching into the instance of the account and setting the “customerName” instance variable itself. It would have to call something like “setCustomerName” or, more reasonably for the sorts of cases you’re talking about, call the “changeCustomerName” method.

This sort of thing is, in fact, what a system with a lot of varied and strange events that can impact a lot of different objects wants to do. First, you don’t want to have to have all of these varied objects actually have to know what the actual logic of changing a customer name is. Not only does this add complexity to them, but it also is a royal pain if you eve

Start the Separatist playthrough in an Obviously Doomed Hometown.

Have really trivial tutorial quests, while dropping hints that the village is about to be attacked by the Empire. At the end, the Empire attacks, but is quickly repelled. The game plays on the player's expectation that the village will be destroyed for drama points.

For every feature, lay out at least one accidental "path" through which the user can stumble on this feature organically.
- Express this path in a data structure that can be checked in CI.
When browsing a hierarchy, make it really easy to quickly see the list of all parents
Do not make the user make changes that they don't know how to cancel. (even without ctrl-Z)
- Cancelling should generally be as easy as "Remove object I just created"
Make "git diff" visible in object hierarchy

Object-oriented smells

Object-oriented programming is widespread in industrial codebases.

This is in part because of inertia: OOP has been the dominant paradigm for decades; an entire generation of programmers has been taught from the onset that OOP was The Right Way To Program.

There are also strong reasons to do OOP: objects are somewhat intuitive abstractions, and encapsulation is a convenient way to separate responsibilities so that a very large team can work on the same code without bumping into each other; inheritance and abstract classes add modularity and reusability to the mix.

But OOP also has strong flaws, which I rarely see discussed. People who criticize OOP tend to do so from the perspective of performance: OOP leads to vtables, heterogenous collections, and sprawling object graphs which put a lot of pressure on CPU caches. But people rarely discuss what I see as the main problem with object-oriented codebases:

	pub trait VirtualDom {
	fn update_value(&mut self, other: Self);

	#[track_caller]
	fn init_tree(&self, cx: &mut Cx);

	fn apply_diff(&self, other: &Self, cx: &mut Cx) -> bool;
	}