I took that to mean ≈ "Amount of training data isn't the big factor dwarfing all else." Depends who "we" refers to, I guess. Back when LLM-generated code was new, I definitely saw predictions that LLMs would struggle with niche or rarely used languages. These days, consensus among colleagues within earshot is that LLMs handle Rust much better than Python or C++ (corpus size and AutoCodeBench scores notwithstanding).

And yet a lot of speakers still seem to need that self-evidently true statement pointed out to them. Tautological advice isn't necessarily bad or useless, especially for beginners.

What percent of own-content submissions are good original content though?

What percent of non-own content is ?

This rule basically says "just submit a bunch of vaguely related crap and shove some of your stuff in-between so nobody can complain".

And for those that really want to promote, do that under some alt-account then go "Hi!, author here, ...." on your main for extra engagement

Does that button... do anything?

If you have to ask: not until you actually use it, no.

> Ever try or even see a "Leet-Code" style question that stated the problem without providing example results?

This style of question asks the examinee to devise a procedure for producing those results, not to come up with the individual results themselves. If a student is given a bunch of systems of linear equations to solve, an answer key isn't especially useful since checking a candidate solution is pretty straightforward.

Teaching isn't likely to get you away from unreasonable people with unreasonable expectations.

We could be extremely, reductively classical about it and say that all of Nerdle's answers point to the same place (⊤, since any answer equivalent to ⊥ is disallowed by the rules), but the real answer is that Nerdle—like Wordle—is simply about finding the right piece of syntax, not finding the right semantics.

> Python's OOP is awkward with object.f() meaning something different from f(object), when really they ought to mean the same thing.

Why should they? Coming from other OO languages, I would expect `object.f()` to involve a vtable lookup, or something similar that effectively has `object` carrying around its own particular implementation of `f` (which might have been closed over some hidden internal state as well), and I'd expect `f(object)` to not do anything of the sort.

> In Pandas, you sometimes have a function with the same name as a method, which behave subtly different from each other.

This sounds more like a poorly designed library than any language-level awkwardness.

> Python's OOP is awkward with object.f() meaning something different from f(object), when really they ought to mean the same thing.

>> Why should they? Coming from other OO languages, I would expect `object.f()` to involve a vtable lookup

Low level details like that should not concern me. In which case, maybe `f(object)` should do a vtable lookup then; why not? The syntax `object.f()` and `f(object)` should be interchangeable in all situations.

> This sounds more like a poorly designed library than any language-level awkwardness.

Languages ought to disallow these things. E.g. I'm constantly baffled that many languages won't let you use symbols as normal method names, but are absolutely fine with you having two methods whose names differ only in case. (There's even academic research showing that case sensitivity is the biggest pitfall for beginners learning Python).

> Figure 2 shows plots of overnight and intraday returns for twenty-one major stock market indices around the world. Turn the page and compare Figure 1 with Figure 2. See if you can tell a difference.

These images... do not render well on my machine, to put it lightly. So they look remarkably similar to me. Perhaps the author could spell out what this difference is? There is eventually mention of "striking similarity in the overnight and in- traday return patterns in the indices around the globe," but I don't think I'm ready to conclude that strong correlation of phenomena across markets in a global economy must be caused by a collection of manipulators acting on all of those markets.

I'm curious to see what others have to say, since I lack the hardware and background to properly read this document.

The issue is about which edges are in the same plane as which other edges. If this is a polyhedron, AD and BE must be coplanar, and BE and CF must be coplanar. Extending the edges into lines, they don't form a 3-way intersection. G gets projected to the same screen point as some point on line AD, but the only way G can be on line AD is if AD and FC are coplanar. If all three of AD, BE, and FC are coplanar, the entire figure is a flat pentagon (and DE, BE, and FE are not edges).

If G isn't on line AD, then BE and CF can't be a side of the same truncated pyramid.